Methods and apparatus for event logging in an information network

ABSTRACT

Methods and apparatus for logging, analysis, and reporting of events such as reboots in a client device (e.g., consumer premises equipment in a cable network) using applications. In one aspect, an improved event logging and monitoring system is provided within the device with which the application(s) can interface to record event or error data. In one exemplary embodiment, the client device comprises a digital set-top box having Java-enabled middleware adapted to implement the various functional aspects of the event logging system, which registers to receive event notifications (including resource exhaustion data) from other applications running on the device. The network operator can also optionally control the operation of the logging system remotely via a network agent. Improved client device and network configurations, as well as methods of operating these systems, are also disclosed.

PRIORITY AND RELATED APPLICATIONS

This application is a continuation of and claims priority to co-ownedand co-pending U.S. patent application Ser. No. 11/897,742 of the sametitle filed Aug. 31, 2007, which is incorporated herein by reference inits entirety, and which is a divisional of co-owned and co-pending U.S.patent application Ser. No. 10/722,206 of the same title filed Nov. 24,2003, incorporated herein by reference in its entirety. This applicationis also related to co-owned and co-pending U.S. patent application Ser.No. 11/897,731 of the same title filed Aug. 31, 2007, also incorporatedherein by reference in its entirety.

COPYRIGHT

A portion of the disclosure of this patent document contains materialthat is subject to copyright protection. The copyright owner has noobjection to the facsimile reproduction by anyone of the patent documentor the patent disclosure, as it appears in the Patent and TrademarkOffice patent files or records, but otherwise reserves all copyrightrights whatsoever.

BACKGROUND OF THE INVENTION

1. Field of Invention

The present invention relates generally to the field of softwareapplications used on an information network (such as a cable televisionnetwork), and specifically to the logging, analysis, and control ofevents occurring on electronic devices used in the network duringoperation of the software.

2. Description of Related Technology

Software applications are well known in the prior art. Such applicationsmay run on literally any type of electronic device, and may bedistributed across two or more locations or devices connected by anetwork. Often, a so-called “client/server” architecture is employed,where one or more portions of applications disposed on client orconsumer premises devices (e.g., PCs, PDAs, digital set-top boxes{DSTBs}, hand-held computers, etc.) are operatively coupled and incommunication with other (server) portions of the application. Such isthe case in the typical hybrid fiber coax (HFC) or satellite contentnetwork, wherein consumer premises equipment or CPE (e.g., DSTBs orsatellite receivers) utilize the aforementioned “client” portions ofapplications to communicate with their parent server portions in orderto provide downstream and upstream communications and data/contenttransfer:

Digital TV (DTV) is an emerging technology which utilizes digitized andcompressed data formats (e.g., MPEG) for content transmission, ascompared to earlier analog “uncompressed” approaches (e.g., NTSC). TheDTV content may be distributed across any number of different types ofbearer media or networks with sufficient bandwidth, including HFC,satellite, wireless, or terrestrial. DTV standards such as the OpenCableApplication Platform middleware specification (e.g., Version 1.0, andincipient Version 2.0) require that applications be downloaded to CPEfrom the bearer or broadcast network in real-time. The OCAPspecification is a middleware software layer specification intended toenable the developers of interactive television services andapplications to design such products so that they will run successfullyon any cable television system in North America, independent of set-topor television receiver hardware or operating system software choices.

Due to the broad variety of applications which can be downloaded overcable networks, and the broad variety of different CPE hardware andmiddleware that can receive such applications, application run-time andother software errors are somewhat inevitable. These errors can resultin both significant frustration for the consumer, and the generation ofmany unnecessary service calls from the cable systems operator or otherservice provider. These deficiencies stem largely from the inability ofexisting cable/CPE devices to (i) log, analyze, and recover from fairlyroutine or non-critical errors; and (ii) communicate with the cablesystems operator. Specifically, a network provider must be able toprocess events occurring within the CPE connected to their networks,including identifying (and ideally diagnosing and correcting) anyerrors. This CPE may include both leased equipment and retail consumerelectronic equipment, and hence any corrective system must be adapted tointerface with a variety of different equipment.

One type of error or event which can occur in cable network CPE is whatis generally referred to as “resource exhaustion”. This term is appliedto a group of different circumstances wherein one or more resourceswithin the CPE (such as memory, CPU capacity, etc.) are at or nearexhaustion, thereby indicating an incipient or prospective errorcondition within an application. As is well known, when resources suchas memory become exhausted within an OCAP compliant Host device (e.g.,set-top box, integrated TV), the application manager within the OCAPsystem will begin destroying applications starting with the lowestpriority application. Hence, the OCAP-compliant CPE employs apriority-based system of resource self-preservation. However, suchsystems are generally not capable of (uniquely) dealing with differenttypes of resource exhaustion, logging data relating to the exhaustionevent(s), or initiating corrective action for other types of eventsoccurring within the CPE (such as thrown but uncaught Java exceptions),or reboot events which are not initiated by the middleware. Accordingly,the OCAP-complaint prior art CPE is generally not as robust as it couldbe, and does not afford the level of control over the CPE operationsduring error conditions that is desired by cable network operators.

A variety of other approaches to error logging and handling withincomputer systems are taught in the prior art. These approaches generallyrange from bit-level systems such as those used in semiconductorapplications, to higher-level functional or behavior logging systems fornetworked computers. For example, U.S. Pat. No. 3,999,051 to Petschauerissued Dec. 21, 1976 and entitled “Error logging in semiconductorstorage units” discloses a maintenance procedure comprising a method ofand an apparatus for storing information identifying the location of oneor more defective bits, i.e., a defective memory element, a defectivestorage device or a failure, in a single-error-correcting semiconductormain storage unit (MSU) comprised of a plurality of large scaleintegrated (LSI) bit planes. The method utilizes an error logging store(ELS) comprised of 128 word-group-associated memory registers. Adefective device counter (DDC) counts the set tag bits in the ELS and isutilized by the machine operator to schedule preventative maintenance ofthe MSU by replacing the defective bit planes. By statisticallydetermining the number of allowable failures, i.e., the number ofcorrectable failures that may occur before the expected occurrence of anoncorrectable double bit error, preventative maintenance may bescheduled only as required by the particular MSU.

U.S. Pat. No. 4,339,657 to Larson, et al. issued Jul. 13, 1982 andentitled “Error logging for automatic apparatus” discloses methods andapparatus for error logging by integrating errors over a given number ofoperations that provides long memory and fast recovery. Errorsintegrated over a selected number of associated operations are comparedto a criterion. An exception is logged each time the number of errors isnot less than the criterion but if the number of errors is less than thecriterion, the exception log is cleared.

U.S. Pat. No. 4,604,751 to Aichelmann, Jr., et al. issued Aug. 5, 1986and entitled “Error logging memory system for avoiding miscorrection oftriple errors” discloses apparatus by which miscorrection of tripleerrors is avoided in a memory system by providing a double bit errorlogging technique. The address of each fetched word is logged in which adouble bit error is detected. The address of each fetched word in whicha single bit error is detected is compared with all logged addresses. Ifa coincidence is found between the compared addresses, a triple biterror alerting signal is generated and error recovery procedures areinitiated.

U.S. Pat. No. 5,121,475 to Child, et al. issued Jun. 9, 1992 andentitled “Methods of dynamically generating user messages utilizingerror log data with a computer system” discloses methods of errorlogging and correction in a communications software system. An error logrequest is generated by a component of the system; the error log requestis analyzed and compared to entries in one of a plurality of records ina message look-up table. If there is a match between the fields of theerror log request and selected entries of a record in the look-up table,a user message request is generated which facilitates the display of apre-existing user friendly message as modified with data included in thegenerated user message request.

U.S. Pat. No. 5,155,731 to Yamaguchi issued Oct. 13, 1992 and entitled“Error logging data storing system” discloses an error logging datastoring system containing a first storing unit for storing error loggingdata corresponding to an error of high importance, a second storing unitfor storing error logging data corresponding to an error of either highor low importance. A first indicating unit indicates whether or not thefirst storing unit is occupied by error logging data the diagnosingoperation of which is not completed. A second indicating unit indicateswhether or not the second storing unit is occupied by error logging datathe diagnosing operation of which is not completed. A storage controlunit stores error logging data corresponding to an error of highimportance in the second storing unit when the first indicating unitindicates that the first storing unit is occupied by error logging datathe diagnosing operation of which is not completed and the secondindicating unit indicates that the second storing unit is not occupiedby error logging data the diagnosing operation of which is notcompleted.

U.S. Pat. No. 5,245,615 to Treu issued Sep. 14, 1993 and entitled“Diagnostic system and interface for a personal computer” discloses apersonal computer having a NVRAM comprising an error log for storingpredetermined error log information at predetermined locations therein.The information is accessible by various programs such as a POSTprogram, a diagnostics program, and an operating system program. Accessis made by BIOS interrupt calls through a BIOS interface. The NVRAM alsostores vital product data and system setup data.

U.S. Pat. No. 5,463,768 to Cuddihy, et al. issued Oct. 31, 1995 andentitled “Method and system for analyzing error logs for diagnostics”discloses an error log analysis system comprising a diagnostic unit anda training unit. The training unit includes a plurality of historicalerror logs generated during abnormal operation or failure from aplurality of machines, and the actual fixes (repair solutions)associated with the abnormal events or failures. A block finding unitidentifies sections of each error log that are in common with sectionsof other historical error logs. The common sections are then labeled asblocks. Each block is then weighted with a numerical value that isindicative of its value in diagnosing a fault. In the diagnostic unit,new error logs associated with a device failure or abnormal operationare received and compared against the blocks of the historical errorlogs stored in the training unit. If the new error log is found tocontain block(s) similar to the blocks contained in the logs in thetraining unit, then a similarity index is determined by a similarityindex unit, and solution(s) is proposed to solve the new problem. Aftera solution is verified, the new case is stored in the training unit andused for comparison against future new cases.

U.S. Pat. No. 5,790,779 to Ben-Natan, et al. issued Aug. 4, 1998 andentitled “Method and system for consolidating related error reports in acomputer system” discloses a method and system for consolidating relatederror reports. In a preferred embodiment, a facility preferablyimplemented in software (“the facility”) receives error reports andsuccess reports generated by programs. When the facility receives anovel error report specifying an error source for which no error stateis set, it sets an error state corresponding to the error report. Thefacility also preferably generates a consolidated error report at thispoint, which is delivered to a error state reporting subsystem. Theerror state reporting subsystem may add the consolidated error report toan error log and/or display it to a user. When the facility receives aredundant error report specifying an error source for which an errorstate is already set, the facility preferably does not set a new errorstate, nor does it generate a consolidated error report. When thefacility receives a success report specifying an error source, it clearsany error states that are set for the specified error source, andpreferably generates a consolidated success report. The performance ofthe facility is preferably optimized by processing success reportsasynchronously.

U.S. Pat. No. 5,862,316 to Hagersten, et al. issued Jan. 19, 1999 andentitled “Multiprocessing system having coherency-related error loggingcapabilities” discloses protocol agents involved in the performance ofglobal coherency activity that detect errors with respect to theactivity being performed. The errors are logged by a computer systemsuch that diagnostic software may be executed to determine the errordetected and to trace the error to the erring software or hardware. Inparticular, information regarding the first error to be detected islogged. Subsequent errors may receive more or less logging dependingupon programmable configuration values. Additionally, those errors whichreceive full logging may be programmably selected via error masks. Theprotocol agents each comprise multiple independent state machines whichindependently process requests. If the request which a particular statemachine is processing results in an error, the particular state machinemay enter a freeze state. Information regarding the request which iscollected by the state machine may thereby be saved for later access. Astate machine freezes upon detection of the error if a maximum number ofthe multiple state machines are not already frozen and theaforementioned error mask indicates that full error logging is employedfor the detected error. Therefore, at least a minimum number of themultiple state machines remain functioning even in the presence of alarge number of errors. Still further, prior to entering the freezestate, the protocol state machines may transition through a recoverystate in which resources not used for error logging purposes are freedfrom the erring request.

U.S. Pat. No. 6,381,710 to Kim issued Apr. 30, 2002 and entitled “Errorlogging method utilizing temporary defect list” discloses an errorlogging method utilizing a temporary defect list to store errorsproduced at or above a predetermined occurrence frequency during adefect detecting test. The method includes the steps of: determiningwhether an error is recorded on a temporary defect list, determiningwhether the error is recorded on an error frequency list when the erroris not recorded on the temporary defect list, adding the error to theerror frequency list if the error is not recorded on the error frequencylist, increasing the occurrence frequency of the error if the error ison the error frequency list, and adding the error to the temporarydefect list if the error has an occurrence frequency greater than orequal to a threshold value established as a standard for classifying anerror as a defect. The temporary defect list can be used as a finalerror list, and thereby reduce memory requirements.

U.S. Pat. No. 6,532,552 to Benignus, et al. issued Mar. 11, 2003 andentitled “Method and system for performing problem determinationprocedures in hierarchically organized computer systems” discloses amethod and system for performing problem determination procedures in ahierarchically organized computer system. The hardware components of thedata processing system are interconnected in a manner in which thecomponents are organized in a logical hierarchy. A hardware-relatederror occurs, and the error is logged into an error log file. At somepoint in time, a diagnostics process is initiated in response to thedetection of the error. The logged error may implicate a particularhardware component, and the hardware component of the data processingsystem is analyzed using a problem determination procedure. In responseto a determination that the hardware component does not have a problem,the logically hierarchical parent hardware component of the hardwarecomponent is selected for analysis. The logically hierarchical parenthardware component is then analyzed using a problem determinationprocedure. The method continues to analyze the logically hierarchicalparent components until the root component is reached or until a faultycomponent is found.

U.S. Pat. No. 6,505,298 to Cerbini, et al. issued Jan. 7, 2003 andentitled “System using an OS inaccessible interrupt handler to reset theOS when a device driver failed to set a register bit indicating OS hangcondition” discloses a method and system for providing a reset after anoperating system (OS) hang condition in a computer system, the computersystem including an interrupt handler not accessible by the OS. Themethod includes determining if an interrupt has been generated by awatchdog timer; monitoring for an OS hang condition by the interrupthandler if the interrupt has been generated and after it is known thatthe OS is operating; and resetting the OS if a device driver within theOS has not set a bit in a register, the bit for indicating that the OSis operating. The method and system in accordance with the presentinvention uses existing hardware and software within a computer systemto reset the OS. The invention uses a method by which a criticalhardware watchdog periodically wakes a critical interrupt handler of thecomputer system. The critical interrupt handler determines if the OS isin a hang condition by polling a share hardware register that a devicedriver, running under the OS, will set periodically. If the criticalinterrupt handler does not see that the device driver has set theregister bit, it will assume the OS has hung and will reset the system.In addition, the critical interrupt handler will store the reset innon-volatile memory. The reset can be logged into the system error log.Because the method and system in accordance with the invention usesexisting hardware and software within the computer system, instead ofrequiring an additional processor, it is ostensibly cost efficient toimplement while also providing a reset of the OS without humanintervention.

Unite States Patent Publication No. 20010007138 to Iida, et al.published Jul. 5, 2001 and entitled “Method and system for remotemanagement of processor, and method and system for remote diagnosis ofimage output apparatus” discloses a method and system for remotemanagement of processors and a method and system for remote diagnosis ofprocessors such as image output apparatus. Operation information aboutcontents of operation performed by a processor during an operationalpreset period or a preset number of executions of processing isrecorded. An operation log is formed by combining the operationinformation and is transferred to a remote management apparatusconnected to the processor by a communication line. The remotemanagement apparatus performs remote management of the condition of theprocessor on the basis of the transmitted operation log. An error logcontaining information about occurrences of errors having occurred inthe processor is also formed and transferred to the remote managementapparatus.

United States Patent Publication No. 20020083214 to Heisig, et al.published Jun. 27, 2002 and entitled “Protocol adapter framework forintegrating non-IIOP applications into an object server container”discloses a method and apparatus for providing access to objects andmethods via arbitrary remote protocols in a computer with object server.This includes a mechanism known as the protocol adapter framework thatallows protocol adapters to manage remote socket sessions, encryptcommunication on this session, translate text to the local characterset, perform security validation of the remote user, log incoming workrequests, classify the incoming work request for differentiated servicepurposes, and queue the work for execution. Also, included is amechanism to invoke the protocol adapter in order to manipulate outputfrom the execution of a method on a server object and send it back tothe original requester. This allows the implementers of objects andmethods that reside in the object server rather than the owner of theobject server to provide a protocol adapter that allows communicationwith remote clients using any arbitrary protocol that the objectimplementer deems appropriate. In this way, the object implementer canenjoy benefits such as differentiated service, workload recording,server object process management, process isolation, error logging,systems management and transactional services of running objects in arobust object server container.

United States Patent Application Publication No. 20020144193 to Hicks,et al. published Oct. 3, 2002 and entitled “Method and system for faultisolation methodology for I/O unrecoverable, uncorrectable error”discloses a method and system for managing uncorrectable data errorconditions from an I/O subsystem as the UE passes through a plurality ofdevices in a central electronic complex (CEC). The method and systemcomprises detecting a I/O UE by at least one device in the CEC; andproviding an SUE-RE (Special Uncorrectable Data Error-Recoverable Error)attention signal by at least one device to a diagnostic system thatindicates the I/O UE condition. The method and system further includesanalyzing the SUE-RE attention signal by the diagnostic system toproduce an error log with a list of failing parts and a record of thelog. The invention provides a fault isolation methodology and algorithm,which allows for the determination of an error source and providesappropriate service action if and when the system fails to recover fromthe UE condition.

United States Patent Application Publication No. 20030041291 to Hashem,et al. published Feb. 27, 2003 and entitled “Method and system fortracking errors” discloses a system and method for tracking errors, thesystem residing on a user's desktop communicating with a centraldatabase over a network. The system comprises an error log includingerror recording tools for enabling the user to record an error; errorresolution tools for enabling the user to resolve the error; and errorfollow-up tools for enabling a user to follow up on resolved errors;error reporting tools for enabling a user to generate error reports fromthe user's desktop; and communication tools for enabling the user totransmit logged errors to the central database and to receive reportsgenerate from errors logged in the central database.

United States Patent Application Publication No. 20030056155 to Austen,et al. published Mar. 20, 2003 and entitled “Method and apparatus forfiltering error logs in a logically partitioned data processing system”discloses a method, apparatus, and computer implemented instructions forreporting errors to a plurality of partitions. Responsive to detectingan error log, an error type for the error log is identified. If theerror log is identified as a regional error log, an identification ofeach partition to receive the error log is made. Then, the error log isreported to each partition that has been identified to receive the errorlog.

United States Patent Application Publication No. 20030105995 toSchroath, et al. published Jun. 5, 2003 and entitled “Method andapparatus for rebooting a printer” discloses detection and logging ofprinter errors in an error log. If the same printer error has occurredwithin a predetermined time period, an error message is generated on theprinter's control panel and a network administrator is notified of theprinter errors. If the same printer error has not occurred within thepredetermined time period, the printer is rebooted. If the same printererror has occurred a predetermined number of consecutive times, an errormessage is generated on the printer's control panel and a networkadministrator is notified of the printer errors. If the same printererror has not occurred a predetermined number of times, the printer isrebooted.

United States Patent Application Publication No. 20030140285 to Wilkiepublished Jul. 24, 2003 and entitled “Processor internal error handlingin an SMP server” discloses a system and method for handling processorinternal errors in a data processing system. The data processing systemtypically includes a set of main microprocessors that have access to acommon system memory via a system bus. The system may further include aservice processor that is connected to at least one of the mainprocessors. In addition, the system includes internal error handlinghardware configured to log and process internal errors generated by oneor more of the main processors. The internal error hardware may includeerror detection logic configured to receive internal error signals fromthe main processors. By incorporating error logging and handling intodedicated hardware tied directly to the processor internal errorsignals, the invention ostensibly provides a lower cost, lower responselatency mechanism for handling processor internal errors in highperformance multiprocessor systems.

The well known Windows® NT operating system manufactured by MicrosoftCorporation includes an error logging capability (“Event Viewer”) thatmay be used on, e.g., data networks including servers. The Event Vieweris a tool used to examine the three NT event logs: System, Security, andApplication.

Each message within the Windows NT error logger has an event ID number.The maximum size of logs can be set, and overriding of log entries canbe set depending on available disk space. System errors include: (i)Information—a significant event has occurred, but the event is notcritical; (ii) Warning—this is a caution indication of a possiblesignificant event which may or may not affect future operations; and(iii) Error—indicates a problem that has caused a failure of service.

Security Log errors include: (i) Success Audit—a successful auditedsecurity event has occurred; and (ii) Failure Audit—a failed auditedsecurity event has occurred.

The exemplary Windows NT Event viewer display includes informationrelating to the date, time, source, category, Event ID number, user, andcomputer to which a given error is related.

The Windows NT system uses a registry to locate files (.EXE or .DLL)that contain resource strings. RegisterEventSource and ReportEventfunctions are provided to log messages to the event log service. Thename specified as a parameter to RegisterEventSource must match the nameof the key in the registry. With Windows NT, each system maintains itsown log files; there is no central storage location.

Similarly, other third party products such as the EventReporter productsold by Adiscon GMbH monitors Windows NT/2000/XP/Server 2003 event logsand reports via syslog or email. Automated monitoring is provided toassist in early detection of problems on the network. For applicationswith a larger number of servers, a centralized log is maintained viasyslog servers available for Windows, Unix, Linux and other operatingsystems. See also the “Snare” freeware product, which collects andprocesses Windows NT Event Log information from multiple event logs, andconverts the information to tab or comma delimited text format anddelivers it via UDP to a remote server.

A recently proposed Home Audio Video Interoperability (HAVi)specification is a consumer electronics (CE) industry standard design topermit digital audio and video devices that conform to this standard,regardless of manufacturer, to interoperate when connected via a networkin the consumer's home. The HAVi standard (e.g., Version 1.1) uses thedigital IEEE-1394 network standard for data transfer between devices andthe 1394 A/VC protocols for device control.

The HAVi standard focuses on the transfer and processing (for example,recording and playback) of digital content between networked devices.HAVi-compliant devices will include not only familiar audio and videocomponents but also cable modems, digital set-top boxes and “smart”storage devices such as personal video recorders (PVRs).

By employing modular software, the HAVi standard allows consumerelectronics devices to identify themselves and what they can do whenplugged into the host. The software functions by assigning a devicecontrol ID module to each hardware component of a system. Each systemalso is assigned multiple functional component modules, containinginformation about an individual device's capabilities, for example,whether a camcorder operates in DV format, or whether a receiver isdesigned to process AC3 audio.

All HAVi APIs involving messaging (e.g., those APIs where theCommunication Type is “M” or “MB”) use a “status” structure consistingof two fields: an API code and an error code. Generally the differentsoftware elements will define their own error codes (see Annex 11.7 ofHAVi Version 1.1). Additionally, there are several “general purpose”error codes that can be used by any software element. These generalerror codes are: (i) SUCCESS—the operation has succeeded (this is thenormal return value in Status and not an error); (ii)EUNKNOWN_MESSAGE—the receiver of a HAVi message does not support the APIindicated by the Operation Code contained within the message; (iii)EACCESS_VIOLATION—the caller of an API does not have permission toperform the operation; (iv) EUNIDENTIFIED_FAILURE—an error of unknownorigin has occurred; (v) ERESERVED—the operation is refused because theFCM (or, in the case of a DCM, one of the FCMs involved in the DCMoperation) is reserved by another software element and the invokingsoftware element (possibly a secondary client) is not allowed to performthis operation; (vi) ENOT_IMPLEMENTED—the receiver of a HAVi messagedoes not implement the optional API indicated by the Operation Codecontained within the message; (vii) EINVALID_PARAMETER—one or moreparameters in a HAVi message contain invalid values; (viii)ERESOURCE_LIMIT—the operation failed due to resource limitations at thedestination device EPARAMETER_SIZE_LIMIT—one or more parameters in aHAVi message exceed their safe; (ix) parameter size limit and thereceiver is unable to handle the parameter(s); (x)EINCOMPLETE_MESSAGE—the length of a HAVi message is shorter than thelength required for compliant messages (using the Operation Codecontained within the message); (xi) EINCOMPLETE_RESULT—one or more outparameters in a HAVi message are correct but incomplete. Note that thismay only occur when one or more parameters are at least the safeparameter size; (xii) ELOCAL—the caller of a “local” API (as indicatedin the “Services Provided” tables) is not on the same device as theprovider of the API; and (xiii) ESTANDBY—the operation is refusedbecause the target device is in standby state.

The error code appearing in the status value returned by a HAVi API iseither: one of the general codes listed above, a Messaging System errorcode, or an API-specific error code (one that is listed in the “Errorcodes” section following the description of the API). If the Statusvalue returned by a HAVi API contains one of the “general error codes”listed above (including SUCCESS), the API code is that used in invokingthe API, otherwise it is the API code associated with the containederror (as identified in Annex 11.7). If the contained error is notlisted in the “Error codes” section following the description of the APIor the contained error has an invalid API code, the client of the APIshall interpret the contained error as EUNIDENTIFIED_FAILURE. Therefore,if the client is a Java client, the corresponding messagesending methodof the client class, server helper class (see section 7.3.8.1.2) or theSoftwareElement class throws HaviUnidentifiedFailureException in thesecases.

In terms of resource limitations, some of the HAVi APIs havespecifications that would allow unbounded sizes for some parameters.However, each FAV and IAV will only have a limited amount of memory.These limitations can differ from controller to controller and thushamper interoperability between controllers. Therefore, for variablesized (input or output) parameters in HAVi APIs a “safe parameter sizelimit” is specified. Such limits indicate that compliant softwareelements will be able to handle messages where the size of the parameterin question is less than or equal to the safe parameter size limit.However, accepting parameters of size larger than the safe parametersize limit is allowed.

The safe parameter size limit puts a requirement to support theindicated parameter size at both sending and receiving sides. At thereceiving side (in parameters for servers, out parameters for clients)this means being able to receive and handle. At the sending side (outparameters for servers, in parameters for clients) this means being ableto construct and send. The server may return the EPARAMETER_SIZE_LIMITerror if it cannot handle the request due to the safe parameter size ofan in parameter being exceeded.

The server returns the EINCOMPLETE_RESULT error if the parameters itreturns are valid but incomplete. Note that a server may only returnthis error when one or more of the parameters it returns are at leastthe safe parameter size.

The server returns ERESOURCE_LIMIT if it fails to process a request dueto lack of resources. If the server generates an incomplete orpotentially incomplete response, i.e., one where values of the outparameters are valid but may be incomplete, this error is not returned.

Despite the foregoing, no suitable methodology or architecture for bothlogging and responding to errors (such as repetitive boots or uncaughtthrown Java exceptions) encountered during operation of networkedsystems has been disclosed under the prior art. This is particularlytrue in the context of leased set-top boxes and OpenCable compliant Hostdevices. Prior art solutions also do not provide the ability to (i)tailor delivery of error and reboot reports to a network agent, and (ii)transfer recovery of exhausted system resources from CPE manufacturercontrol to network operator control.

Accordingly, there is a need for improved apparatus and methods forproviding error logging, diagnosis, operation, and control ofapplications within such networks. These improved apparatus and methodswould meet these needs while also enabling compliance with industrystandard requirements within the network.

SUMMARY OF THE INVENTION

The present invention addresses the foregoing needs by disclosing animproved error logging and response apparatus and associated methods.

In a first aspect of the invention, an improved method of operatingclient equipment in a content-based network is disclosed. The methodgenerally comprises: generating first data relating to the operation ofthe equipment; receiving, at a first application, the first data;evaluating the first data; and selectively storing at least a portion ofsaid first data within a storage device. In one exemplary embodiment,the client equipment comprises an OCAP-compliant set-top box or similardevice having middleware comprising an event logging system registeredto receive event notifications form other applications or hardware. Thesystem is also adapted to evaluate the received notifications andclassify them according to priority.

In a second aspect of the invention, an improved method of operating CPEhaving resources within a content-based network is disclosed. In oneexemplary embodiment, the CPE includes an event logging system adaptedto communicate with another network entity, and a plurality of softwareapplications. The CPE evaluates the resource(s) using the loggingsystem; and in response thereto selectively controls the operation ofone or more of the applications, including selective destruction thereofbased on depletion of the resources.

In a third aspect of the invention, fault-tolerant CPE adapted forcoupling to a cable network is disclosed. The CPE generally comprises amonitor application miming thereon and adapted to (i) detect at leastone event relating to the operation of one or more software applicationsrunning thereon; (ii) selectively log data relating to the event forsubsequent use; and (iii) control the operation of the CPE based atleast in part on the detected event. In one exemplary embodiment, themonitor application is further adapted to communicate with an externalentity such as a network agent. The monitor can both log errors forretrieval by the network agent, and selectively suspend or destroysoftware applications in order to mitigate resource depletion.

In a fourth aspect of the invention, an improved method of operating acable network having a plurality of client devices operatively coupledthereto is disclosed, the method generally comprising: distributing atleast one software application to each of the plurality of devices;providing at least one monitor entity to each of the devices; monitoringthe operation of the software application(s) with respective ones of themonitor applications; detecting events associated with the operation ofthe software application(s); and responsive to such detecting, logging aplurality of data relating to the events within the devices forsubsequent use. In the exemplary embodiment, the network comprises anHFC network with a plurality of DSTBs attached. A trusted monitorapplication implements the event logging system on the DSTBs, thelogging system adapted to both selectively store data regarding varioustypes of events, and provide access to the stored data to another agenton the network The monitor and agent may also institute correctiveaction for the event as required.

In a fifth aspect of the invention, an improved head-end apparatus foruse in a cable network is disclosed. The apparatus generally comprisesat least one server having a software process running thereon, thesoftware process being adapted to selectively interface with at leastone client device and retrieve logged error data therefrom. In theexemplary configuration, the head-end apparatus is disposed within anHFC network having an SMS, CMTS, and application distribution servers.The software process is adapted to communicate with the client deviceevent logging system via either in-band or OOB channels.

In a sixth aspect of the invention, an improved error logging systemadapted for use on a consumer electronics device is disclosed. Thesystem generally comprises: an event registration entity; an eventsubmission entity; an event database; a priority event reporting entity,a network retrieval entity; and a resource depletion registrationentity. In one exemplary embodiment, the device comprises a set-top boxhaving OCAP-compliant middleware comprised of at least a portion of theaforementioned functional entities. The entities comprise objects withina Java programming environment and the network retrieval entitycomprises a portion of a client-server architecture by which the variousentities in the logging system can be accessed and controlled remotely.

In a seventh aspect of the invention, a method of conducting businessvia a cable network having a plurality of client devices with eventlogging systems is disclosed. The method generally comprises:distributing a software application to the plurality of devices; runningthe software application; receiving an event notification via the eventlogging system; evaluating the notification to determine a correctiveaction; and selectively controlling a function within the device usingthe event logging system to implement at least a portion of thecorrective action. In one embodiment, the event logging system comprisesmiddleware running on the device, the middleware comprising a pluralityof APIs. Selective control is accomplished via one or more of the APIs.The event logging system can also be selectively enabled based on one ormore subscription policies in effect on the network for individualsubscribers.

These and other aspects of the invention shall become apparent whenconsidered in light of the disclosure provided below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a functional block diagram illustrating an exemplary HFCnetwork configuration useful with the present invention.

FIG. 1 a is a functional block diagram illustrating one exemplaryhead-end configuration of an HFC network useful with the presentinvention.

FIG. 2 is a logical flow diagram illustrating one exemplary embodimentof the event logging and management methodology according to theinvention.

FIG. 2 a is a logical flow diagram illustrating an exemplary method ofregistering for resource exhaustion events using the error loggingsystem of the invention.

FIG. 3 is a functional block diagram of exemplary CPE having theimproved error logging and management system.

FIG. 3 a is a logical block diagram illustrating the relationshipsbetween the various components within the CPE, and the error loggingsystem.

FIG. 4 is a logical block diagram illustrating the relationships betweenthe various entities associated with the error logging system of theinvention.

DETAILED DESCRIPTION OF THE INVENTION

Reference is now made to the drawings wherein like numerals refer tolike parts throughout.

As used herein, the term “application” refers generally to a unit ofexecutable software that implements theme-based functionality The themesof applications vary broadly across any number of disciplines andfunctions (such as e-commerce transactions, brokerage transactions,mortgage interest calculation, home entertainment, calculator etc.), andone application may have more than one theme. The unit of executablesoftware generally runs in a predetermined environment; for example, theunit could comprise a downloadable Java Xlet™ that runs within theJavaTV™ environment.

As used herein, the term “computer program” is meant to include anysequence or human or machine cognizable steps which perform a function.Such program may be rendered in virtually any programming language orenvironment including, for example, C/C++, Fortran, COBOL, PASCAL,assembly language, markup languages (e.g., HTML, SGML, XML, VoXML), andthe like, as well as object-oriented environments such as the CommonObject Request Broker Architecture (CORBA), Java™ (including J2ME, JavaBeans, etc.) and the like.

As used herein, the term “middleware” refers to software that generallyruns primarily at an intermediate layer in a software or protocol stack.For example, middleware may run on top of an operating system andplatform hardware, and below applications.

The term “component” refers generally to a unit or portion of executablesoftware that is based on a related set of functionalities. For example,a component could be a single class in Java™ or C++. Similarly, the term“module” refers generally to a loosely coupled yet functionally relatedset of components.

As used herein, the term “process” refers to executable software thatruns within its own CPU environment. This means that the process isscheduled to run based on a time schedule or system event. It will haveits own Process Control Block (PCB) that describes it. The PCB willinclude items such as the call stack location, code location, schedulingpriority, etc. The terms “task” and “process” are typicallyinterchangeable with regard to computer programs.

A server process is an executable software process that serves variousresources and information to other processes (clients) that requestthem. The server may send resources to a client unsolicited if theclient has previously registered for them, or as the application authordictates.

As used herein, the term “DTV Network Provider” refers to a cable,satellite, or terrestrial network provider having infrastructurerequired to deliver services including programming and data over thosemediums.

As used herein, the terms “network” and “bearer network” refer generallyto any type of telecommunications or data network including, withoutlimitation, hybrid fiber coax (HFC) networks, satellite networks, telconetworks, and data networks (including MANs, WANs, LANs, WLANs,internets, and intranets). Such networks or portions thereof may utilizeany one or more different topologies (e.g., ring, bus, star, loop,etc.), transmission media (e.g., wired/RF cable, RF wireless, millimeterwave, optical, etc.) and/or communications or networking protocols(e.g., SONET, DOCSIS, IEEE Std. 802.3, ATM, X.25, Frame Relay, 3GPP,3GPP2, WAP, SIP, UDP, FTP, RTP/RTCP, H.323, etc.).

As used herein, the terms “head-end” refers generally to a networkedsystem controlled by an operator (e.g., an MSO or multiple systemsoperator) that distributes programming to MSO clientele using clientdevices. Such programming may include literally any informationsource/receiver including, inter alia, free-to-air TV channels, pay TVchannels, interactive TV, and the Internet. DSTBs may literally take onany configuration, and can be retail devices meaning that consumers mayor may not obtain their DSTBs from the MSO exclusively. Accordingly, itis anticipated that MSO networks may have client devices from multiplevendors, and these client devices will have widely varying hardwarecapabilities. Multiple regional head-ends may be in the same ordifferent cities.

As used herein, the terms “client device” and “end user device” include,but are not limited to, personal computers (PCs) and minicomputers,whether desktop, laptop, or otherwise, set-top boxes such as theMotorola DCT2XXX/5XXX and Scientific Atlanta Explorer2XXX/3XXX/4XXX/8XXX series digital devices, personal digital assistants(PDAs) such as the Apple Newton®, “Pal,®” family of devices, handheldcomputers such as the Hitachi “VisionPlate”, personal communicators suchas the Motorola Accompli devices, Motorola EVR-8401, J2ME equippeddevices, cellular telephones, or literally any other device capable ofinterchanging data with a network.

Similarly, the terms “Consumer Premises Equipment (CPE)” and “hostdevice” refer to any type of electronic equipment located within aconsumer's or user's premises and connected to a network. The term “hostdevice” refers generally to a terminal device that has access to digitaltelevision content via a satellite, cable, or terrestrial network. Thehost device functionality may be integrated into a digital television(DTV) set. The term “consumer premises equipment” (CPE) includes suchelectronic equipment such as set-top boxes, televisions, Digital VideoRecorders (DVR), gateway storage devices (Furnace), and ITV PersonalComputers.

As used herein, the term “network agent” refers to any network entity(whether software, firmware, and/or hardware based) adapted to performone or more specific purposes. For example, a network agent may comprisea computer program running in server belonging to a network operator,which is in communication with one or more processes on a CPE or otherdevice.

As used herein, the term “DOCSIS” refers to any of the existing orplanned variants of the Data Over Cable Services InterfaceSpecification, including for example DOCSIS versions 1.0, 1.1 and 2.0.DOCSIS (version 1.0) is a standard and protocol for Internet accessusing a “digital” cable network. DOCSIS 1.1 is interoperable with DOCSIS1.0, and has data rate and latency guarantees (VoIP), as well asimproved security compared to DOCSIS 1.0. DOCSIS 2.0 is interoperablewith 1.0 and 1.1, yet provides a wider upstream band (6.4 MHz), as wellas new modulation formats including TDMA and CDMA. It also providessymmetric services (30 Mbps upstream).

The term “processor” is meant to include any integrated circuit or otherelectronic device (or collection of devices) capable of performing anoperation on at least one instruction including, without limitation,reduced instruction set core (RISC) processors, CISC microprocessors,microcontroller units (MCUs), CISC-based central processing units(CPUs), and digital signal processors (DSPs). The hardware of suchdevices may be integrated onto a single substrate (e.g., silicon “die”),or distributed among two or more substrates. Furthermore, variousfunctional aspects of the processor may be implemented solely assoftware or firmware associated with the processor.

Overview

As previously discussed, a network provider such as a cable systemoperator needs to be able to process events, including identifying (andideally diagnosing and correcting) any errors that are occurring withinconsumer premises equipment (CPE) connected to their networks. This CPEmay include both leased equipment and retail consumer electronicequipment. Moreover, the ability to communicate with the CPE via thenetwork or other communications channel is useful in handling, and incertain cases obviating, consumer calls and complaints.

The improved event logging and management apparatus and methodsdescribed herein provide mechanisms by which the cable system operatoror other entity can gain such insight into CPE events and errors (suchas those generated by other applications running on the CPE) as well asother operational aspects of the CPE. This substantially enhances therobustness of the CPE and network in general. In an exemplaryconfiguration, an API is provided to trusted downloaded networkapplications resident on the CPE thereby enabling these applications todiscover the error(s), report them to the network operator, andoptionally recover from them autonomously or under supervisory controlof an external agent. A trusted application such as the monitorapplication defined by the OCAP 1.0 specification is configured toregister with the implementation (a.k.a. middleware) to receive eventnotifications, such as for example Java exceptions thrown by anapplication but not caught by the application, and take appropriateaction; e.g., reboot in cases where the error was not caused by themonitor application. The error logging system advantageously allows theregistered trusted application to store the information received byaforementioned events for retrieval by a network agent where/whenconvenient for the agent, or where required by another process. Inaddition, the registered trusted application is optionally programmed bythe network operator to generate and deliver one or more error messagesor communications of suitable priority. These messages may be ofpredetermined format/content, or alternatively customized to theparticular context of the error experienced by the CPE.

In the context of a typical OCAP-based configuration (e.g., OCAP 1.0),the application manager program within the OCAP system may begindestroying applications, starting with the lowest priority application,when resources (e.g., memory or CPU usage) become exhausted. Exhaustionof system resources may comprise an error (i.e., one type of “event”)that is reportable to the registered trusted application. In anotheraspect of the invention, a second registration is optionally providedthat allows a trusted application to selectively determine whichapplications are destroyed. Thus, a network application decides whichapplications are destroyed when system resources are exhausted, ratherthan the application manager as under the prior art. This approachtransfers the recovery control of the exhausted system resources fromthe CPE manufacturer (via the application manager) to the networkoperator, thereby providing the network operator with enhanced errorrecovery capabilities.

Detailed Description of Exemplary Embodiments

Exemplary embodiments of the apparatus and methods of the presentinvention are now described in detail. While these exemplary embodimentsare described in the context of the aforementioned hybrid fiber coax(HFC) cable system architecture having a multiple systems operator(MSO), digital networking capability, and plurality of clientdevices/CPE, the general principles and advantages of the invention maybe extended to other types of networks and architectures, whetherbroadband, narrowband, wired or wireless, or otherwise, the followingtherefore being merely exemplary in nature.

It will also be appreciated that while described generally in thecontext of a consumer (i.e., home) end user domain, the presentinvention may be readily adapted to other types of environments (e.g.,commercial/enterprise, government/military, etc.) as well. Myriad otherapplications are possible.

FIG. 1 illustrates a typical network component configuration with whichthe hardware registry apparatus and methods of the present invention maybe used. The various components of the network 100 include (i) one ormore application origination points 102; (ii) one or more distributionservers 104; and (iii) consumer premises equipment (CPE) 106. Thedistribution server(s) 104 and CPE(s) 106 are connected via a bearer(e.g., HFC) network 101. A simple architecture comprising one of each ofthe aforementioned components 102, 104, 106 is shown in FIG. 1 forsimplicity, although it will be recognized that comparable architectureswith multiple origination points, distribution servers, and/or CPEdevices (as well as different network topologies) may be utilizedconsistent with the invention. For example, the head-end architecture ofFIG. 1 a (described in greater detail below) may be used.

The application origination point 102 comprises any medium that allowsan application to be transferred to a distribution server 104. This caninclude for example an application vendor website, CD-ROM, externalnetwork interface, mass storage device (e.g., RAID system), etc. Suchtransference may be automatic, initiated upon the occurrence of one ormore specified events (such as the receipt of a request packet or ACK),performed manually, or accomplished in any number of other modes readilyrecognized by those of ordinary skill.

The distribution server 104 comprises a computer system where one ormore applications can enter the network system. Distribution servers arewell known in the networking arts, and accordingly not described furtherherein.

The CPE 106 includes any equipment in the “consumers' premises” (orother locations, whether local or remote to the distribution server 104)that can be accessed by a distribution server 104. Such CPEs 106comprise processors and associated computer memory adapted to store andrun the downloaded or resident application. In the present context, atleast a portion of the application is typically downloaded to the CPE106, wherein the latter executes the downloadedapplication(s)/components, although it will be recognized that all ofapplications may conceivably be uploaded to the server, or alternativelytransferred to another device, such as other networked CPE or the like.Applications may be (i) “pushed” to the CPE (i.e., wherein thedistribution server causes the application download to occur), (ii)“pulled” to the CPE (i.e., where the CPE causes the download), (iii)downloaded as the result of some third entity or device (such as aremote server); (iv) resident on the CPE at startup; or (v) combinationsof the foregoing.

Referring now to FIG. 1 a, one exemplary embodiment of the networkhead-end architecture useful with the invention is described. As shownin FIG. 1 a, the head-end architecture 150 comprises typical head-endcomponents and services including billing module 152, subscribermanagement system (SMS) and CPE configuration management module 154,cable-modem termination system (CMTS) and OOB system 156, as well asLAN(s) 158, 160 placing the various components in data communicationwith one another. It will be appreciated that while a bar or bus LANtopology is illustrated, any number of other arrangements as previouslyreferenced (e.g., ring, star, etc.) may be used consistent with theinvention. It will also be appreciated that the head-end configurationdepicted in FIG. 1 a is high-level, conceptual architecture and thateach MSO may have multiple head-ends deployed using customarchitectures.

The architecture 150 of FIG. 1 a further includes amultiplexer/encrypter/modulator (MEM) 162 coupled to the HFC network 101adapted to “condition” content for transmission over the network. In thepresent context, the distribution servers 104 are coupled to the LAN160, which provides access to the MEM 162 and network 101 via one ormore file servers 170.

In the typical HFC network, information is carried across multiplechannels. Thus, the head-end must be adapted to acquire the informationfor the carried channels from various sources. Typically, the channelsbeing delivered from the head-end 150 to the CPE 106 (“downstream”) aremultiplexed together in the head-end and sent to neighborhood hubs (notshown).

Content (e.g., audio, video, etc.) is provided in each downstream(in-band) channel. To communicate with the head-end, the CPE 106 usesthe out-of-band (OOB) or DOCSIS channels and associated protocols. TheOCAP 1.0 specification provides for networking protocols both downstreamand upstream. To distribute files and applications to the CPE 106, thefiles and applications are configured as data and object carousels andmay be sent in both the in-band and OOB channels. As is well known inthe art, a carousel may be viewed as a directory containing files. Thefiles of the carousel utilized herein are sent in a continuousround-robin fashion. If the client device misses a desired or necessaryfile in one carousel transmission, it can wait for the next.Alternatively, in another embodiment, the CPE portion of the applicationis configured as part of the program content on a given in-band orDOCSIS channel. As yet another embodiment, the CPE portion is downloadeddirectly using IP (Internet Protocol) packet traffic in an Out-Of-Bandchannel. Note that the file carousel or other device providing theapplication to the CPE 106 via the aforementioned communication channelsmay be the distribution server 104 previously described, oralternatively a separate device which may or may not be physicallyco-located with the server (e.g., remote file servers 170 of FIG. 1 a).For example, a remote file storage device (not shown) with carouselcapability may be in data communication with the client device(s) via anout-of-band communications channel as described below, the download ofthe application files from the remote device being initiated by way of aquery from the client device, or alternatively a signal generated by theserver 104 and transmitted to the remote device. Many other permutationsof the foregoing system components and communication methods may also beused consistent with the present invention, as will be recognized bythose of ordinary skill in the field.

Referring now to FIG. 2, a first exemplary embodiment of the generalizederror logging methodology of the invention is described. As shown inFIG. 2, the first step 202 of the methodology 200 comprises generating asuitable software interface (e.g., application programming interface, orAPI) adapted to provide access to the error logging services andcapabilities described subsequently herein. Software interfacegeneration methods are well known in the art, and accordingly notdescribed further herein. It will be recognized that while the followingdiscussion is cast in terms of traditional forms of APIs (such as thoserendered in Java language), other types of interfaces may be utilized.

The software interface generated in step 202 is particularly adapted toprovide the CPE to which it is distributed with enhanced error-loggingcapabilities. This is accomplished via association within an applicationdownloaded or otherwise provided to the CPE, such as a trustedOCAP-compliant monitor application of the type well known in the cablesoftware arts. The trusted application, via the APIs, in effectregisters to receive various types of messages and exceptions.

Note that the interface(s) provided with the trusted application may begeneric in nature, such as for example one or more APIs having apredetermined configuration or standardization. Alternatively, theinterface(s) may be customized to the particular application or CPE towhich it will be distributed. Combinations of standardized andnon-standardized/customized APIs may be utilized as well in order todifferentiate various services or features within the error loggingsystem.

Per step 204, the API(s) generated in step 202 are distributed to theCPE 106, such as via one or more trusted network applications. Forexample, OCAP 1.0 specifies that applications are Java-based. OCAP usesthe Java-based permission scheme to provide various capabilities toapplications in the network. Signed (trusted) applications are capableof receiving permissions in addition to those available to unsignedapplications. In addition, an MSO or other entity can selectively assignapplication permissions to trusted applications of their choice. Monitorapplication permissions defined by OCAP give an application the abilityto perform system level functions such as rebooting the CPE 106.

The distribution of the trusted application/APIs per step 204 may occurdirectly over a primary content channel of the network, via one or moreOOB channels, via an alternate network interface to the CPE (e.g.,Internet download via DSL or dial-up connection), or even via hard mediasuch as CD-ROM provided to the CPE user. The API(s) may be deliveredwith the target “trusted” CPE application, such as at time ofconfiguration of the CPE by the network operator or at time ofmanufacture, or alternatively delivered subsequently to the CPE aftersetup, such as in the form of discrete software modules which areappended to or otherwise integrated with the existing target (trusted)application. Hence, the API(s) may be both included in newinstallations, as well as being retrofit onto older or existing CPE. Aswill be recognized by those of ordinary skill, myriad different schemesfor delivery of the API(s) may be used consistent with the inventiondescribed herein.

Lastly, per step 206, the distributed API(s) is/are operated inconjunction with the monitor or other middleware and network to provideerror logging, diagnosis, and/or correction capabilities. In oneexemplary configuration, the APIs and CPE target application operateonly to register and log errors as described in greater detail below.This baseline configuration may be optimal for very “thin” or low-endclient devices where only a minimal logging and recovery capability isdesired, or where only minimal subscription service options are selectedby the consumer (e.g., basic service). Alternatively, more capable APIpackages and applications may be provided which provide enhanced errorlogging, diagnosis, and recovery capabilities.

A second registration mechanism is also optionally provided by theinvention, whereby the trusted application can be informed when systemresources are nearing exhaustion, and make decisions regardingdestruction of unnecessary or low priority applications, in order toattempt to recover needed resources (see FIG. 2 a). Additional“intelligence” is programmed into the trusted (e.g., monitor)application, or other software which signals the monitor, to analyzerelevant data and identify these conditions or trends. This approach,while ostensibly consuming more resources within the CPE during normaloperations (due to increased software overhead resident on the CPE),advantageously allows the monitor or other trusted application topotentially identify trends or other artifacts within resources orrunning applications, and take appropriate action before an error orother deleterious event is encountered. This approach also providesenhanced continuity of operations for the user and network operator,thereby increasing the satisfaction of the former and the revenuegeneration of the latter.

In the exemplary method 250 of FIG. 2 a, the trusted application isfirst registered to receive signaled data relating to resourceexhaustion and utilization (step 252). Where the trusted (e.g., monitor)application in the CPE 106 detects an impending exhaustion of memory orCPU via the aforementioned signaling/registration (step 254), it canoptionally analyze the data (step 256) and selectively suspend ordestroy one or more applications in anticipation of the exhaustion (step258). This avoids failure or interruption of the in-focus applicationrunning on the CPE and presenting a seamless user experience. Asdescribed in greater detail subsequently herein, this destruction mayoccur according to any number of different schemes, such as based on afixed parameter associated with the application(s) (e.g., applicationsize), a variable parameter associated with the application (e.g.,number of resource or service calls issued per unit time), or otherstatic or dynamic prioritization scheme.

The trusted application of the present invention may also be configuredwith additional intelligence wherein periodic, situational, ordeterministic polling of other applications and resources is conducted,and/or corrective actions for error recovery are implemented by thetrusted application(s). For example, the trusted application may beconfigured to recognize situations and/or applications where thelikelihood of particular types or errors is increased, and adjust itsoperational characteristics accordingly. Such recognition may be basedon historical data logged by the trusted application (e.g., where agiven application or combination of applications has caused a particulartype of error in the past), or alternatively on more inductive facultiesprovided to the monitor (e.g., the analysis and recognition ofcombinations of two or more parameters or events within the CPE whichare known to increase the likelihood of errors).

FIG. 3 illustrates a first embodiment of the improved electronic devicewith error logging capability according to the present invention. Asshown in FIG. 3, the device 300 generally comprises andOpenCable-compliant embedded system having an RF front end 302(including modulator/demodulator) for interface with the HFC network 101of FIG. 1, digital processor(s) 304, storage device 306, and a pluralityof interfaces 308 (e.g., video/audio interfaces, IEEE-1394 “Firewire”,USB, serial/parallel ports, etc.) for interface with other end-userapparatus such as televisions, personal electronics, computers, WiFi orother network hubs/routers, etc. Other components which may be utilizedwithin the device (deleted from FIG. 3 for simplicity) include RF tunerstages, various processing layers (e.g., DOCSIS MAC, OOB channels, MPEG,etc.) as well as media processors and other specialized SoC or ASICdevices. These additional components and functionality are well known tothose of ordinary skill in the cable and embedded system fields, andaccordingly not described further herein.

The device 300 of FIG. 3 is also provided with an OCAP 1.0-compliantmonitor application and Java-based middleware which, inter alit:,manages the operation of the device and applications running thereon. Itwill be recognized by those of ordinary skill that myriad differentdevice and software architectures may be used consistent with thehardware registry of the invention, the device of FIG. 3 being merelyexemplary. For example, different middlewares (e.g., MHP, MHEG, or DASE)may be used in place of the OCAP middleware of the illustratedembodiment.

As previously described, the error logging functionality of theinvention is embodied primarily in (i) the device middleware, includingAPIs specific to the error logging system, (ii) the on-board or remotestorage available to the CPE, and (iii) an optional network agent orother entity in communication with the error logger. In the illustratedembodiment (FIG. 3 a), the trusted application 352 is configured toregister to receive events 354 such as error messages explicitly sent bya running application 356, Java exceptions and errors thrown (but notcaught) by the application, resource depletion events, reboot events notcaused by the monitor application 352, or other types of occurrencessuch as, for example, a “power-on” message. These error messages arereceived in real-time by the optional event handling agent. If no suchagent is registered, the events are dropped. If such an agent isregistered it may store the event messages on a storage device forretrieval by a network server agent.

The error logging system 350 allows the registered trusted application302 to store the information received by such events. The events arestored, for example, in the form of human and/or machine-readable filesor records within the storage device 306 disposed on the CPE 106 (e.g.,RAM, ROM, memory card, hard drive, etc.), although the data may also besent or streamed off-CPE to a remote storage location if desired.

The use of human-readable error logs or records within the storagedevice 306 of the exemplary embodiment advantageously allows an analyst(which may comprise anyone ranging from the consumer to MSO personnel toa third party provider) to rapidly evaluate the type and cause of theerror. For example, the human readable data may include the date/time ofthe event, category of the event, source application or entity, CPEtype, a log of other applications running at the time of the event, anyrecently monitor-initiated reboot events, etc. This aids the analyst indiagnosing the problem rapidly, and instituting corrective action asrequired. Note that the “analyst” may also comprise a software entity orother process which is adapted to automatically review certain fieldswithin the stored event report, and initiate further actions basedthereon. In this latter context, it may none-the-less be desirable toretain the human-readable format in the event that the software analystis not successful in its resolution.

As used above, the term “other use” may comprise anything ranging fromimmediate, concurrent use of the information by the monitor or anotherentity or agent (e.g., another application 362 running on the CPE 106,or a network agent 364) to subsequent use (e.g., transmission via anetwork agent to the MSO and analysis thereby).

In one exemplary embodiment, the logged data is retrieved by a networkagent 364 at a point in time that is convenient or optimal for thenetwork agent or for the network as a whole. For example, periodicpolling of connected CPE 106 by a network agent 364 tasked withcollecting network-wide error or failure data may be used. As anotheralternative, an “immediate” approach may be used (e.g., over anyavailable channel, or in conjunction with a carrier access techniquesuch as FDMA, TDMA, ALOHA, or CSMA/CD on an OOB channel), wherein errormessages are promptly sent to the network agent, proxy, or other networkprocess when received and processed by the monitor application on theCPE. These event messages may be generated consistent with any number ofwell-known communications protocols and transmitted via literally anytype of communications channels, whether in-band, out-of-band, orcompletely unrelated to the bearer network. For example, an upstream OOBchannel is used in one embodiment to transmit TCP/IP protocol messages.In another embodiment, the CPE 106 is 3G-enabled (e.g., WAP/WTLS orGPRS) and utilizes a wireless CDMA, GSM, or satellite uplink to PSDN orsimilar infrastructure. Many other alternatives are possible and readilyimplemented by those of ordinary skill given the present disclosure.

In yet another embodiment, a priority-based approach is implementedwherein the registered trusted application is programmed by the networkoperator (such programming which may be situationally invoked by thehead-end 100, agent 364, or CPE 106 itself) to deliver them according tothe priority scheme. Any event logging entity (i.e., application orimplementation) sets the event priority when logging an event. Forexample, a three-tiered classification system may be used whichclassifies errors or other events as being either “catastrophic”,“recoverable”, or “informational” in nature. It will be recognized thatthis three-tier system is merely illustrative of the broader concept ofa multi-tiered classification approach; any number of different classesand types of event (some which may overlap other classes/types) may beused consistent with the invention. The following exemplary event typerange scheme is used in conjunction with the Java code appended heretoto identify and store different event types:

0x00000000-0x0FFFFFFF—reserved for informational message types;

0x10000.000-0x1FFFFFFF—reserved for recoverable error types;

0x20000000-0x2FFFFFFF—reserved catastrophic error types;

0x30000000-0x3FFFFFFF—reserved for reboot events;

0x40000000-0x4FFFFFFF—reserved for resource depletion events; and

0x50000000-0xFFFFFFFF—reserved for proprietary use.

Along with an event type code each event logged may include a humanreadable string message and in the Java case a String that indicates astacktrace of the most recently called methods and an array of Stringsthat indicate the class hierarchy of the error or exception, otherwiseknown as a Throwable object.

Catastrophic and recoverable events may instigate generation of animmediate message to the network agent or other cognizant entity, whileinformational events may be issued on an as-available basis, oralternatively bundled into a common message with other informationalevents (or higher priority “targets of opportunity” concurrently beingissued by the monitor) in order to reduce processing overhead andbandwidth consumption. A plethora of different prioritization schemesfor various types or errors and events will be readily apparent to thoseof ordinary skill given the present disclosure.

The foregoing prioritization approach also provides, inter cilia, theability for the agent 362, 364 to apply its own prioritization mask(e.g., message handling algorithm) in dealing with one or more suchevent messages. Where multiple event messages are received by thecognizant agent in close temporal proximity, such as where a streamedapplication or content may be adversely affecting a class of CPE orcustomers for whatever reason, the agent can prioritize action on thesemessages according to its own mechanisms or those of a parent entity,which may or may not consider the priority of the event message issuedby each CPE. For example, one approach handles all events in order ofpriority and time of message issuance (or receipt) as determined by themessage local time stamp; i.e., process all catastrophic events intime-order sequence until exhausted, then process all recoverable alertsin time-order sequence until exhausted, and so forth.

Alternatively, other information can be used within the agent's messagehandling algorithm in place of or in conjunction with thepriority/timing information, such as geographic location, customersubscription class (e.g., basic or “full service”), etc. Similarly, thehandling algorithm of the agent may be configured to analyze the contentof one or more classes of message (e.g., all catastrophic eventmessages) immediately upon receipt in order to extract additional dataor information as to the nature of the event, such additional data beinguseful in further prioritizing the events for follow-on action by theagent or its proxy.

It will be recognized that the aforementioned error message handlingparadigms may also comprise a multi-tiered or decoupled approach to theactual data transmission. For example, in one exemplary variant, theerror logging system 300 of the invention (FIG. 3) is adapted to useshort, low-overhead “signaling” messages which are issued by themonitor, or a designated proxy process, to the network agent in lieu ofa complete transmission of the logged error data. These signalingmessages may be used, for example, to alert the agent as to theexistence of an error/event condition (including priority level, ifdesired) on one or more CPE 106 which has been logged into local storageon the affected CPE.

As will be described in greater detail below, certain errors and eventscan be handled sufficiently by assets within the CPE 106 itself, therebynot requiring additional intervention by the MSO, user, etc.Accordingly, the improved monitor application described herein (oranother associated “local” agent process disposed on the CPE) can ineffect pre-process any error messages to (i) log all pertinent datarelating to the event for later use; (ii) determine if any correctiveaction is required; and (iii) determine whether the required correctiveaction can be effectuated by the monitor application or other residentprocess. Where additional intervention beyond that which the monitor canprovide is required, an event message of the type described above may beissued to the network agent or other comparable entity to initiate suchintervention.

Referring now to FIG. 4, the various components of an exemplary errorlogging system according to the invention are described in greaterdetail, in the context of a Java-based programming environment. Thisenvironment is selected for its ease of programming and implementation,especially in conjunction with the system architecture of FIGS. 3 and 3a. It will be readily appreciated, however, that the use of Java in thisembodiment is merely illustrative; the various logging system componentsadvantageously may be implemented using any one or more differentcomputer languages (including, without limitation C, C++, and Ada), andwithin various middleware environments (e.g., MHP, OCAP, MHEG, DASE),thereby providing significant flexibility of design. Furthermore, thefollowing discussion illustrates but a sample of the possible constructswithin the Java environment that are useful with the broader principlesof the invention. For purposes of illustration, other “real-world”issues such as multi-threading have been omitted from the sample codeprovided herein (Appendices I-XV); however, such issues are readilyaddressed by those of ordinary skill provided the present disclosure.

As shown in FIG. 4, the error logging system 350 generally consists ofthe following major components: (i) an event registration entity 402;(ii) an event submission entity 404; (iii) an event database. 406; (iv)an emergency event reporting entity 408; (v) a network event retrievalentity 410; and (vi) a resource depletion registration entity 412. Thesevarious entities are now discussed in greater detail. It will berecognized that not all of the entities listed above are required foroperation of the event logging system 350; rather, various levels offunctionality can be achieved by adding more or less of these entitiesas appropriate. Hence, the system 350 is inherently modular.

Furthermore, it will be appreciated that other types of entities (andconfigurations of each) may be utilized, the following being merelyillustrative of the broader principles.

Event registration entity—This entity 402 comprises a software processwhich provides the system 350 with a mechanism to register to receiveerror/event and informational messages from other applications orprocesses within the CPE 106, including notification of (non-monitorinitiated) reboot events, and reason(s) there for. In the exemplaryembodiment, it is rendered within the OCAP Implementation using an API.

Appendix I provides code describing an exemplary system registrationhandler which provides event registration within the system 350.

Appendix II provides exemplary code implementing extensions of systembasic permission for the trusted application registering to handlelogged events. In OCAP this permission is unnecessary and can be addedto the existing monitor application permission class.

Appendix III provides exemplary code implementing the event handlerwhich was registered by the trusted application and called by theimplementation when an event is logged. Appendix IV provides a sampleerror handling application using the IEventHandler of Appendix

Event submission entity—This entity 404 provides the system 350 with themechanism by which applications may log an error/event message with thesystem or the registered trusted application. As previously describedherein, messages can be logged using any number of different priorityschemes (such as the three-tiered catastrophic/recoverable/informationalapproach). Appendix V provides exemplary Java code implementing anEventProcessor class used for handling event submissions fromapplications. Appendix VI provides exemplary error event codeimplementing an error event class. This class represents an eventreturned by the system when an uncaught exception or error isencountered. Appendix VII provides exemplary code implementingmessage-based events (e.g., informational, recoverable, catastrophic,reboot, etc.). Appendix VIII provides exemplary code implementingreporting of a reboot event within the CPE (via the IMessageEvent ofAppendix VII). Appendix IX provides a sample reboot generating systemfor generating trusted application (e.g., monitor application) rebootevents.

Event Database—The event database 406 comprises in the illustratedembodiment a message database wherein a trusted application may storeerror and informational messages for retrieval by a network agent orother entity (whether local or remote from the database/CPE). Theillustrated database 406 is disposed on the CPE 106 itself, although itwill be appreciated that other locations may be used including, forexample, other devices within the particular end-user environment, MSOoperated networked servers, or even third-party servers or storagefacilities. Appendix X provides exemplary Java code implementing asample error logging application for logging events within the database406. Appendix XI provides a sample application for handling rebootevents, including disposing them within an array of the database 406.

Emergency Event Reporting Entity—This entity 408 comprises a networkcommunications definition for, e.g., immediate delivery of selectevent/error and informational messages by a trusted application (such asthe OCAP-compliant monitor described above) to a network agent or otherentity. This provides the system 350 with a rapid mechanism to alert theMSO or another remote entity of impending or existing trouble within theCPE. In the illustrated embodiment, this entity 408 comprises a messagesystem whereby a registered error handler determines that the error orevent is critical enough to inform the network agent immediately. Aclient-server architecture of the type well known in the networking artsis used to implement this system, although other approaches (includingthe various message distribution and prioritization schemes discussedpreviously herein) may be substituted with equal success.

Remote Event Retrieval—This entity 410 comprises a (network)communications definition for retrieval of messages in the messagedatabase by an agent, the latter which may be internal or external tothe CPE 106, such as a remote network agent. This is to be contrastedwith the emergency reporting entity 408, which is tasked with issuingalerts of one form or another to the agent. As with the emergency eventreporting entity 408, the event retrieval entity 410 of the exemplaryembodiment comprises a client-server based message system whereby theagent polls clients based on, e.g., a round-robin schedule arranged tominimize network impact, or any other selected scheme as previouslydescribed herein. Hence, this entity 410 provides access to stored dataand records of the CPE irrespective of their priority.

Resource Depletion Registration Entity—This entity 412 comprises amechanism to register to receive messages regarding the incipientexhaustion of system resources such as memory and CPU bandwidth. Asdiscussed previously herein, a variety of different schemes may be usedto determine (i) proximity (in time or another parameter) to anexhaustion event; (ii) the priority associated with any data or messagesreceived by the mechanism 412; and (iii) the corrective actions to beinitiated in response to the message. For example, where impendingmemory exhaustion is detected (such as through periodic or situationalcomparison of data representing the current available memory to thetotal or nominal memory capacity of the CPE), a message will be issuedto the depletion registration entity 412 indicating the same. Dependingon how emergent the need for action is, the message may be coded as topriority level; e.g., low, medium, or high priority. The depletionentity 412, upon receipt of the message, may be configured toselectively destroy running applications according to a secondarypriority scheme (which may, for example, be dictated by the monitorapplication running on the CPE 106 or another entity in communicationwith the CPE 106); e.g., destroy applications according to a particularsequence or hierarchy, such as largest first, non “in-focus” first, etc.Myriad other schemes are possible. The MHP and OCAP standards, forexample, specify functionality that provides an application destructionhierarchy which may be used with the invention.

Appendix XII provides exemplary Java code implementing the notification(i.e., in the form of a ResourceDepletionEvent class) within the systemwhen a resource depletion event occurs. Appendices XIII and XIV providecode illustrating exemplary resource depletion event generating systemsand resource depletion event handling applications, respectively.

Appendix XV provides exemplary code implementing the class for testingof the reboot, event (error), and depletion handlers.

In addition to the foregoing, the event logging system of the presentinvention is also optionally provided with other functional entitieswhich perform various purposes within the system relating to error/eventhandling. Specifically, a trusted application priority entity (notshown) is optionally provided to indicate to the system 400 that thetrusted application shall handle near-exhaustion events, and that thesystem handlers of such events should provide no handling of suchevents. In the case of the attached exemplary code, the act ofregistering for depletion event receipt (by the depletion entity 412)performs this task as well. Alternatively, these functions may also beseparated so that an application can register to receive the eventmessages, but not be required to act upon them, other than to record theevent and perhaps send it to a network agent or other entity (“recordand relay” function).

The error logging system of the present invention can alsoadvantageously be used without interfering with other functions residentin the CPE, such as for example the hardware registry described inco-owned and co-pending U.S. patent application Ser. No. 10/723,959 Nov.24, 2003 and entitled “METHODS AND APPARATUS FOR HARDWARE REGISTRATIONIN A NETWORK DEVICE”, incorporated herein by reference in its entirety.For example, events or errors generated through access or manipulationof the hardware registry and its various associated options (such as ahardware failure or contention deadlock) can be stored and accessed asdesired by a network agent in order to troubleshoot such errors, andpotentially obviate service calls relating thereto.

It will be recognized that while certain aspects of the invention aredescribed in terms of a specific sequence of steps of a method, thesedescriptions are only illustrative of the broader methods of theinvention, and may be modified as required by the particularapplication. Certain steps may be rendered unnecessary or optional undercertain circumstances. Additionally, certain steps or functionality maybe added to the disclosed embodiments, or the order of performance oftwo or more steps permuted. All such variations are considered to beencompassed within the invention disclosed and claimed herein.

While the above detailed description has shown, described, and pointedout novel features of the invention as applied to various embodiments,it will be understood that various omissions, substitutions, and changesin the form and details of the device or process illustrated may be madeby those skilled in the art without departing from the invention. Theforegoing description is of the best mode presently contemplated ofcarrying out the invention. This description is in no way meant to belimiting, but rather should be taken as illustrative of the generalprinciples of the invention. The scope of the invention should bedetermined with reference to the claims.

APPENDIX I SYSTEM HANDLER REGISTRAR © Copyright 2003 Time Warner Cable,Inc. All rights reserved. import java.lang.*; import java.security.*;/**  * Registration mechanism for trusted applications to set the errorhandler.  */ public class SysHandlerRegistrar {  public final static intERROR_INFO_EVENT_HANDLER = 0x0;  public final static intREBOOT_EVENT_HANDLER = 0x1;  public final static intRESOURCE_DEPLETION_EVENT_HANDLER = 0x2;  private staticSysHandlerRegistrar theSHR = null;  private static IEventHandlertheErrorInfoEventHandler = null;  private static IEventHandlertheRebootEventHandler = null;  private static IEventHandlertheResourceDepletionHandler = null;  /**   * Zero argument constructoris protected so an application cannot create it.   */  protectedSysHandlerRegistrar( )  {  }  /**   * Get the singleton instance of thesystem handler registrar.   *   * @param type -ERROR_INFO_EVENT_HANDLER, REBOOT_EVENT_HANDLER, or   *RESOURCE_DEPLETION_HANDLER.   *   * @return The system handlerregistrar.   */  public static SysHandlerRegistrar getInstance( )  {  if(theSHR == null)    theSHR = new SysHandlerRegistrar( );   returntheSHR;  }  /**   * Get the system system handler.   *   * @param type -ERROR_INFO_EVENT_HANDLER, REBOOT_EVENT_HANDLER, or   *RESOURCE_DEPLETION_HANDLER.   *   * @return Currently registered handlerfor the type specified.   *   * @throws SysHandlerPermission if theapplication does not have permission   * to get the handler.   */ public static IEventHandler getEventHandler(int type) throwsSecurityException  {   SysHandlerPermission ehp = newSysHandlerPermission(“getEventHandler”);   // If the caller does nothave permission the AccessController will throw a   //SecurityException.   //AccessController.checkPermission(ehp); to beuncommented   if(type == ERROR_INFO_EVENT_HANDLER)    returntheErrorInfoEventHandler;   else    if(type == REBOOT_EVENT_HANDLER)    return theRebootEventHandler;    else     returntheResourceDepletionHandler;  }  /**   * Set the system event handler.  *   * @param type - ERROR_INFO_EVENT_HANDLER, REBOOT_EVENT_HANDLER, or  * RESOURCE_DEPLETION_HANDLER.   *   * @param seh - System eventhandler created by the registering application.   *   * @throwsEventHandlerPermission if the application does not have permission   *to set the handler.   */  public static void setEventHandler(int type,IEventHandler seh) throws SecurityException  {   SysHandlerPermissionehp = new SysHandlerPermission(“setEventHandler”);   // If the callerdoes not have permission the AccessController will throw a   //SecurityException.   //AccessController.checkPermission(ehp); to beuncommented   if(type == ERROR_INFO_EVENT_HANDLER)   theErrorInfoEventHandler = seh;   else    if(type ==REBOOT_EVENT_HANDLER)     theRebootEventHandler = seh;    else    theResourceDepletionHandler = seh;  }  /**   * Unset the systemevent handler.   *   * @param type - ERROR_INFO_EVENT_HANDLER,REBOOT_EVENT_HANDLER, or   * RESOURCE_DEPLETION_HANDLER.   *   * @throwsEventHandlerPermission if the application does not have permission   *to unset the handler.   */  public static void unsetEventHandler(inttype) throws SecurityException  {   SysHandlerPermission ehp = newSysHandlerPermission(“setEventHandler”);   // If the caller does nothave permission the AccessController will throw a   //SecurityException.   //AccessController.checkPermission(ehp); to beuncommented   if(type == ERROR_INFO_EVENT_HANDLER)   theErrorInfoEventHandler = null;   else    if(type ==REBOOT_EVENT_HANDLER)     theRebootEventHandler = null;    else    theResourceDepletionHandler = null;  } }

APPENDIX II SYSTEM HANDLER PERMISSION © Copyright 2003 Time WarnerCable, Inc. All rights reserved. import java.security.*; public finalclass SysHandlerPermission extends BasicPermission {  publicSysHandlerPermission(String permissionName)  {   super(permissionName); }  public SysHandlerPermission(String permissionName, String actions) {   super(permissionName, actions);  } }

APPENDIX III IEVENT HANDLER © Copyright 2003 Time Warner Cable, Inc. Allrights reserved. /**  * Event handler implemented by a trustedapplication and registered with  * EventHandlerRegistrar.  */ publicinterface IEventHandler {  /**   * The system will call this method whenan error/info/reboot event is   * incurred and a trusted application hasregistered to receive them.   *   * @param see - event encountered bythe middleware.   *   * @return If the registered application willcompletely handle this   * event, null is returned, otherwise the eventcan be modified or   * returned unchanged and the system will handle it.  */  public IMessageEvent receiveEvent(IMessageEvent see);  /**   * Getany events saved by the handler.   *   * @return The array of events ornull if none were stored.   */  public IMessageEvent [ ] getEvents( ); }

APPENDIX IV ERROR HANDLING APPLICATION © Copyright 2003 Time WarnerCable, Inc. All rights reserved. public class ErrorHandlingAppSampleimplements IEventHandler {  private final static int MAX_EVENT_STORE =5;  private final static int ID_FOR_APP_SAMPLE = 55; // typically set bythe system  private static int eventCount = 0;  private IMessageEvent [] imeStore = new IMessageEvent[MAX_EVENT_STORE];  /**   * The zeroargument constructor demonstrates a possible application example where  * the application registers to receive error events, logs events, andregisters to   * receive reboot events. The SysSample class containsthat code that will generate   * a sample reboot event.   */  publicErrorHandlingAppSample( )  {   // Get the default system error handlerregistrar.   SysHandlerRegistrar ehr =   SysHandlerRegistrar.getInstance( );   // Set this object as the newerror handler.  ehr.setEventHandler(SysHandlerRegistrar.ERROR_INFO_EVENT_HANDLER,this);  }  /**   * Receive a message event from the EventProcessor. Thismethod will be used to process   * all of the error and informationalmessages sent to the registered error handler and   * otherapplications. This sample simply places the messages into an array.Additional   * processing is specific to the application. For example,an application may look at   * the error code and application identifierof the event and take recovery action for   * specific errors. In caseof a critical error the handler may send a message to a   * serveragent.   *   * @param see - Event generated by the system or sent by anapplication.   *   * @return The event unchanged, or the event modifiedto suit the purposes of the   * registered registered event handler, ornull to indicate that the registered handler   * has consumed the event.  */  public IMessageEvent receiveEvent(IMessageEvent see)  {  System.out.print(“ErrorHandlingAppSample.receiveEvent( ); event type:”);   System.out.print(see.getTypeCode( ));   System.out.print(“; date:”);   System.out.println(see.getDate( ));   eventCount = (eventCount ==MAX_EVENT_STORE − 1) ? 0 : eventCount + 1;   imeStore[eventCount] =see; // Store the event for later retrieval.   return null;  // Tell theEventDatabase that the registered handler has consumed        // theevent.  }  /**   * Get any events saved by the handler. A network serveragent may poll a client agent   * running in the same device as thishandler so that the client agent can get the   * events using thismethod.   *   * @return The array of events or null if none were stored.  */  public IMessageEvent [ ] getEvents( )  {   return imeStore;  } }

APPENDIX V EVENT PROCESSOR © Copyright 2003 Time Warner Cable, Inc. Allrights reserved public class EventProcessor {  // The singleton eventdatabase.  private static EventProcessor el = null;  // Get the eventhandler  private static SysHandlerRegistrar ehr =    SysHandlerRegistrar.getInstance( );  private static IEventHandlerseh = null;  private EventProcessor( )  {  }  public staticEventProcessor getInstance( )  {   if(el == null)    el = newEventProcessor( );   return el;  }  public static IMessageEventlog(IMessageEvent meIn)  {   IMessageEvent me = meIn;   if(me instanecofErrorEvent) {    if((seh =ehr.getEventHandler(SysHandlerRegistrar.ERROR_INFO_EVENT_HANDLER) !=null)     me = seh.receiveEvent(meIn);    else    System.out.println(me.getDate( ));   }   else if(me instanceofRebootEvent) {    if((seh =ehr.getEventHandler(SysHandlerRegistrar.REBOOT_EVENT_HANDLER)) != null)    me = seh.receiveEvent(meIn);    else    System.out.println(me.getDate( ));   }   else {    if((seh =ehr.getEventHandler(      SysHandlerRegistrar.RESOURCE_DEPLETION_EVENT_HANDLER)) != null)    me = seh.receiveEvent(meIn);    else    System.outprintln(me.getDate( ));   }   return me;  }          }

APPENDIX VI ERROR EVENT © Copyright 2003 Time Warner Cable, Inc. Allrights reserved. import java.lang.*; import java.util.*; /** */ publicclass ErrorEvent implements IMessageEvent {  public final static intINFO_SHUTDOWN_IMMINENT = 0x0;  public final static intERROR_UNCAUGHT_JAVA_EXCEPTION = 0X30000001;  // Static error event Idnumber. Incremented for each new event  private static long lastEventId; private long eventId;  private long appId;  private int typeCode; private long date;  private Sting message;  private ThrowableerrorOrException;  /**   * Thee argument ErrorEvent constructor.   *   *@param typeCodeIn - The value indicating the error; see IMessageEvent.  *   * @param errorMsg - The readable error message in the followingformat:   */  public ErrorEvent(int typeCodeIn, long appIdIn, StringmessageIn)  {   this(typeCodeIn, appIdIn, messageIn, null);  }  /**   *Four argument ErrorEvent constructor.   *   * @param errorType - Thevalue indicating the error; see IMessageEvent.   *   * @param errorMsg -The readable error message in the following format:   */  publicErrorEvent(int typeCodeIn,     long appIdIn,     String messageIn,    Throwable errorOrExceptionIn)  {  lastEventId = (lastEventId ==Long.MAX_VALUE) ? 0 : lastEventId + 1;  eventId = lastEventId;  typeCode= typeCodeIn;  date = System.currentTimeMillis( );  message = messageIn; errorOrException = errorOrExceptionIn;  }  /**   * Get the uniqueidentifier of the event.   *   * @return unique identifier of the event.  */  public long getEventId( )  {   return eventId;  }  /**   * Get theunique identifier of the application that logged the event.   *   *@return The application identifier.   */  public long getAppId( )  {  return appId;  }  /**   * Get the event type code. Identifies a codespecific to the event system.   *   * @return type code of the event.  */  public int getTypeCode( )  {   return typeCode;  }  /**   * Setthe error type code. Allows an application to change the error received.  *   * @param error - The new error value.   */  public voidsetTypeCode(int typeCodeIn)  {   typeCode = typeCodeIn;  }  /**   * Getthe event date in milli-seconds from midnight January 1, 1970.   *   *@return Date the event was submitted to the system.   */  public longgetDate( )  {   return date;  }  /**   * Set the date. Allows anapplication to change the date received.   *   * @param error - The newerror value.   */  public void setDate(long dateIn)  {   date = dateIn; }  /**   * Get the readable message.   *   * @return the readable eventmessage.   */  public String getMessage( )  {   return message;  }  /**  * Set the error message string. Allows an application to change theerror message received.   *   * @param error - The new error message.  */  public void setErrorMessage(String messageIn)  {   message =messageIn;  }  protected void finalize( )  {   // Store thelastErrorEventId in a persistent storage object.  }  static {  if(/*somepersistent storage object exists with error event Id stored in it*/true)   lastEventId = /* value in the persistent storage object */1; else    lastEventId = 0;  } }

APPENDIX VII IMESSAGE EVENT © Copyright 2003 Time Warner Cable, Inc. Allrights reserved. public interface IMessageEvent {  /*   *0x00000000-0x0FFFFFFF are reserved for informational message   types,  * 0x10000000-0x1FFFFFFF are reserved for recoverable error types,   *0x20000000-0x2FFFFFFF are reserved catastrophic error types,   *0x30000000-0x3FFFFFFF are reserved for reboot events,   *0x40000000-0x4FFFFFFF are reserved for resource depletion events,   *0x50000000-0xFFFFFFFF are reserved for proprietary use.   */  /**   *Get the unique identifier of the event.   *   * @return uniqueidentifier of the event.   */  public long getEventId( );  /**   * Getthe unique identifier of the application logging the event.   *   *@return The identifier of the application.   */  public long getAppId();  /**   * Get the event type code. Identifies a code specific to theevent   system.   *   * @return type code of the event.   */  public intgetTypeCode( );  /**   * Get the event date in milli-seconds frommidnight January 1, 1970.   *   * @return Date the event was submittedto the system.   */           public long getDate( );

APPENDIX VIII REBOOT EVENT © Copyright 2003 Time Warner Cable, Inc. Allrights reserved. import java.lang.*; public class RebootEvent implementsIMessageEvent {  public final static int REBOOT_BUTTON_PRESSED =0x30000001;  public final static int REBOOT_BY_IMPLEMENTATION =0x30000002;  public final static int REBOOT_BY_TRUSTED_APP = 0x30000003; public final static int REBOOT_FOR_UNHANDLED_SYS_ERROR = 0x30000004; public final static int REBOOT_FOR_UNHANDLED_APP_ERROR = 0x30000005; // Static reboot event Id number. Incremented for each new event. private static long lastEventId;  private long eventId;  private longappId;  private int typeCode;  private long date;  private Stringmessage;  public RebootEvent(int typeCodeIn, long appIdIn, StringmessageIn)  {   lastEventId = (lastEventId == Long.MAX_VALUE) ? 0 :lastEventId + 1;   eventId = lastEventId;   typeCode = typeCodeIn;  appId = appIdIn;   date = System.currentTimeMillis( );   message =messageIn;  }  /**   * Get the unique identifier of the event.   *   *@return unique identifier of the event.   */  public long getEventId( ) {   return eventId;  }  /**   * Get the unique identifier of theapplication logging the event.   *   * @return The applicationidentifier.   */  public long getAppId( )  {   return eventId;  }  /**  * Get the event type code. Identifies a code specific to the eventsystem.   *   * @return type code of the event.   */  public intgetTypeCode( )  {   return typeCode;  }  /**   * Set the error typecode. Allows an application to change the error received.   *   * @paramerror - The new error value.   */  public void setTypeCode(inttypeCodeIn)  {   typeCode = typeCodeIn;  }  /**   * Get the event datein milli-seconds from midnight January 1, 1970.   *   * @return Date theevent was submitted to the system.   */  public long getDate( )  {  return date;  }  /**   * Set the date. Allows an application to changethe date received.   *   * @param error - The new error value.   */ public void setDate(long dateIn)  {   date = dateIn;  }  /**   * Getthe readable message.   *   * @return the readable event message.   */ public String getMessage( )  {   return message;  }  protected voidfinalize( )  {   // Store the lastRebootEventId in a persistent storageobject.  }  static {   if(/*some persistent storage object exists withreboot event Id stored in it*/ true)    lastEventId = /* value in thepersistent storage object */1;   else    lastEventId = 0;  }           }

APPENDIX IX REBOOT GENERATING SYSTEM © Copyright 2003 Time Warner Cable,Inc. All rights reserved. public class RebootGeneratingSysSample { private final static int ID_FOR_APP_SAMPLE = 55; // typically set bythe system  /**   * The zero argument constructor demonstrates apossible application example where   * the application registers toreceive error events, logs events, and registers to   * receive rebootevents. The SysSample class contains that code that will generate   * asample reboot event.   */  public RebootGeneratingSysSample( )  {   //Create an error event.   RebootEvent re = newRebootEvent(RebootEvent.REBOOT_BY_IMPLEMENTATION,       0,      “TestReboot”);   // Get the default system event logger.  EventProcessor ep = EventProcessor.getInstance( );   for(int i = 0; i< 5; i++) {    // Log an error to the default system error handler.   ep.log(re);    re.setDate(System.currentTimeMillis( ));   re.setTypeCode(re.getTypeCode( ) + 1);    try    {    Thread.sleep(500);    }    catch (InterruptedException ie)    {    }  }  } }

APPENDIX X ERROR LOGGING APP © Copyright 2003 Time Warner Cable, Inc.All rights reserved. public class ErrorLoggingAppSample {  private finalstatic int ID_FOR_APP_SAMPLE = 55; // typically set by the system  /**  * The zero argument constructor demonstrates a possible applicationexample where   * the application registers to receive error events,logs events, and registers to   * receive reboot events. The SysSampleclass contains that code that will generate   * a sample reboot event.  */  public ErrorLoggingAppSample( )  {   // Create an error event.  ErrorEvent see = newErrorEvent(ErrorEvent.ERROR_UNCAUGHT_JAVA_EXCEPTION,          ID_FOR_APP_SAMPLE,           “TestEvent”);   // Get thedefault system event logger.   EventProcessor el =EventProcessor.getInstance( );   for(int i = 0; i < 5; i++) {    // Logan error to the default system error handler.    el.log(see);   see.setDate(System.currentTimeMillis( ));   see.setTypeCode(see.getTypeCode( ) + 1);    try    {    Thread.sleep(500);    }    catch (InterruptedException ie)    {    }  }  } }

APPENDIX XI REBOOT HANDLING © Copyright 2003 Time Warner Cable, Inc. Allrights reserved. public class RebootHandlingAppSample implementsIEventHandler {  private final static int MAX_EVENT_STORE = 5;  privatefinal static int ID_FOR_APP_SAMPLE = 55; // typically set by the system private static int eventCount = 0;  private IMessageEvent [ ] imeStore= new IMessageEvent[MAX_EVENT_STORE];  /**   * The zero argumentconstructor demonstrates a possible application example where   * theapplication registers to receive error events, logs events, andregisters to   * receive reboot events. The SysSample class containsthat code that will generate   * a sample reboot event.   */  publicRebootHandlingAppSample( )  {   // Get the default system error handlerregistrar.   SysHandlerRegistrar ehr =   SysHandlerRegistrar.getInstance( );   // Set this object as the newreboot handler.  ehr.setEventHandler(SysHandlerRegistrar.REBOOT_EVENT_HANDLER, this); }  /**   * Receive a message event from the EventProcessor. This methodwill be used to process   * all of the reboot messages sent to theregistered error handler by the system.   * This sample simply placesthe messages into an array. Additional processing is   * specific to theapplication. For example, an application may look at   * the reboot codeof the event and take action for specific types of reboots. In case   *of a critical or recurring reboot problem the handler may send a messageto a   * server agent.   *   * @param see - Event generated by thesystem or sent by an application.   *   * @return The event unchanged,or the event modified to suit the purposes of the   * registeredregistered event handler, or null to indicate that the registeredhandler   * has consumed the event.   */  public IMessageEventreceiveEvent(IMessageEvent see)  {  System.out.print(“RebootHandlingAppSample.receiveEvent( ); event type:”);   System.out.print(see.getTypeCode( ));   System.out.print(“; date:”);   System.out.println(see.getDate( ));   eventCount = (eventCount ==MAX_EVENT_STORE − 1) ? 0 : eventCount + 1;   imeStore[eventCount] = see; // Store the event for later retrieval.   return null;   // Tell theEventDatabase that the registered handler has consumed       // theevent.  }  /**   * Get any events saved by the handler. A network serveragent may poll a client agent   * running in the same device as thishandler so that the client agent can get the   * events using thismethod.   *   * @return The array of events or null if none were stored.  */  public IMessageEvent [ ] getEvents( )  {   return imeStore;  } }

APPENDIX XII RESOURCE DEPLETION EVENT © Copyright 2003 Time WarnerCable, Inc. All rights reserved. import java.lang.*; import java.util.*;/**  * Event returned by the system when an uncaught exception or erroris encountered.  */ public class ResourceDepletionEvent implementsIMessageEvent {  public final static int RESOURCE_SYS_MEM_DEPLETED =0X40000001;  public final static int RESOURCE_CPU_BANDWIDTH_DEPLETED =0X40000002;  public final static int RESOURCE_OUT_OF_SYS_MEM =0X40000100;  // Static error event Id number. Incremented for each newevent.  private static long lastEventId;  private long eventId;  privatelong appId;  private int typeCode;  private long date;  private Stringmessage;  /**   * Create a SystemErrorEvent.   *   * @param errorType -The value indicating the error; see IMessageEvent.   *   * @paramerrorMsg - The readable error message in the following format:   */ public ResourceDepletionEvent(int typeCodeIn, long appIdIn, StringmessageIn)  {   lastEventId = (lastEventId == Long.MAX_VALUE) ? 0 :lastEventId + 1;   evenId = lastEventId;   typeCode = typeCodeIn;   date= System.currentTimeMillis( );   message = messageIn;  }  /**   * Getthe unique identifier of the event.   *   * @return unique identifier ofthe event.   */  public long getEventId( )  {   return eventId;  }  /**  * Get the unique identifier of the application that logged the event.  *   * @return The application identifier.   */  public long getAppId()  {   return appId;  }  /**   * Get the event type code. Identifies acode specific to the event system.   *   * @return type code of theevent.   */  public int getTypeCode( )  {   return typeCode;  }  /**   *Set the error type code. Allows an application to change the errorreceived.   *   * @param error - The new error value.   */  public voidsetTypeCode(int typeCodeIn)  {   typeCode = typeCodeIn;  }  /**   * Getthe event date in milli-seconds from midnight January 1, 1970.   *   *@return Date the event was submitted to the system.   */  public longgetDate( )  {   return date;  }  /**   * Set the date. Allows anapplication to change the date received.   *   * @param error - The newerror value.   */  public void setDate(long dateIn)  {   date = dateIn; }  /**   * Get the readable message.   *   * @return the readable eventmessage.   */  public String getMessage( )  {   return message;  }  /**  * Set the error message string. Allows an application to change theerror message received.   *   * @param error - The new error message.  */  public void setErrorMessage(String messageIn)  {   message =messageIn;  }  protected void finalize( )  {   // Store thelastErrorEventId in a persistent storage object.  }  static {  if(/*some persistent storage object exists with error event Id storedin it*/ true)    lastEventId = /* value in the persistent storage object*/1;   else    lastEventId = 0;  } }

APPENDIX XIII RESOURCE DEPLETION EVENT GENERATING SYSTEM © Copyright2003 Time Warner Cable, Inc. All rights reserved. public classResourceDepletionEventGeneratingSysSample {  private final static intID_FOR_APP_SAMPLE = 55; // typically set by the system  /**   * The zeroargument constructor demonstrates a possible application example where  * the application registers to receive error events, logs events, andregisters to   * receive reboot events. The SysSample class containsthat code that will generate   * a sample reboot event.   */  publicResourceDepletionEventGeneratingSysSample( )  {    // Create an errorevent.    ResourceDepletionEvent rde = new ResourceDepletionEvent(     ResourceDepletionEvent.RESOURCE_OUT_OF_SYS_MEM,      0,     “TestReboot”);   // Get the default system event logger.  EventProcessor ep = EventProcessor.getInstance( );   for(int i = 0; i< 5; i++) {    // Log an error to the default system error handler.   ep.log(rde);    rde.setDate(System.currentTimeMillis( ));   rde.setTypeCode(rde.getTypeCode( ) + 1);    try    {    Thread.sleep(500);    }    catch (InterruptedException ie)    {    }  } }         }

APPENDIX XIV RESOURCE DEPLETION EVENT HANDLING APPLICATION © Copyright2003 Time Warner Cable, Inc. All rights reserved. public classResourceDepletionEventHandlingAppSample implements IEventHandler { private final static int MAX_EVENT_STORE = 5;  private final static intID_FOR_APP_SAMPLE = 55; // typically set by the system  private staticint eventCount = 0;  private IMessageEvent [ ] imeStore = newIMessageEvent[MAX_EVENT_STORE];  /**   * The zero argument constructordemonstrates a possible application example where   * the applicationregisters to receive error events, logs events, and registers to   *receive reboot events. The SysSample class contains that code that willgenerate   * a sample reboot event.   */  publicResourceDepletionEventHandlingAppSample( )  {   // Get the defaultsystem error handler registrar.   SysHandlerRegistrar ehr =    SysHandlerRegistrar.getInstance( );   // Set this object as the newreboot handler.  ehr.setEventHandler(SysHandlerRegistrar.RESOURCE_DEPLETION_EVENT_HANDLER,this);  }  /**   * Receive a message event from the EventProcessor. Thismethod will be used to process   * all of the resource depletionmessages sent to the registered error handler by the system.   * Thissample simply places the messages into an array. Additional processingis   * specific to the application. An application may look at theresource depletion   * code of the event and take action for specifictypes of events. For example; if the   * system is running out of memorythe handler may kill low priority applications in an   * effort to getsome back. The same might be true for CPU bandwidth. In case of a   *critical error the handler may send a message to a server agent.   *   *@param see - Event generated by the system or sent by an application.  *   * @return The event unchanged, or the event modified to suit thepurposes of the   * registered registered event handler, or null toindicate that the registered handler   * has consumed the event.   */ public IMessageEvent receiveEvent(IMessageEvent see)  {  System.out.print(“ResourceDepletionEventHandlingAppSample.receiveEvent(); event type: ”);   System.out.print(see.getTypeCode( ));  System.out.print(“; date: ”);   System.out.println(see.getDate( ));  eventCount = (eventCount == MAX_EVENT_STORE − 1) ? 0 : eventCount + 1;  imeStore[eventCount] = see;  // Store the event for later retrieval.  return null;   // Tell the EventDatabase that the registered handlerhas consumed        // the event.  }  /**   * Get any events saved bythe handler. A network server agent may poll a client agent   * runningin the same device as this handler so that the client agent can get the  * events using this method.   *   * @return The array of events ornull if none were stored.   */  public IMessageEvent [ ] getEvents( )  {  return imeStore;  } }

APPENDIX XV TEST ERROR APPLICATION © Copyright 2003 Time Warner Cable,Inc. All rights reserved. /**  * Main class for testing the reboot,error, and resource depletion handlers. Note that all  * can beregistered for in the same manner.  */ public class TestErrorApp { public static void main(String [ ] args)  {   RebootHandlingAppSamplerhas = new RebootHandlingAppSample( );   RebootGeneratingSysSample rgss= new RebootGeneratingSysSample( );   ErrorHandlingAppSample ehas = newErrorHandlingAppSample( );   ErrorLoggingAppSample elas = newErrorLoggingAppSample( );   ResourceDepletionEventHandlingAppSamplerdhas = new ResourceDepletionEventHandlingAppSample( );  ResourceDepletionEventGeneratingSysSample rdgss = new      ResourceDepletionEventGeneratingSysSample( );  } }

1.-50. (canceled)
 51. Apparatus adapted for operation within a contentdelivery network, said apparatus comprising: a network interface adaptedfor communication with said content delivery network; a digitalprocessor; a storage device operatively coupled to said processor;middleware adapted to run on said processor; and software comprising aplurality of privileged application programming interfaces (APIs), saidprivileged APIs adapted to be accessed by only an application withspecial permission to do so; wherein said APIs are further adapted toenable at least one of the reporting and handling of events occurringwithin said apparatus, said events relating to at least one resource ofsaid apparatus.
 52. The apparatus of claim 51, wherein said privilegedapplication programming interfaces (APIs) comprise Java classes andmethods particularly adapted to support said application with specialpermission.
 53. The apparatus of claim 52, wherein said application withspecial permission comprises a monitor application.
 54. The apparatus ofclaim 51, wherein said at least one resource comprises availablestorage, and said handling comprises removal or destruction of at leastone application resident on said apparatus.
 55. The apparatus of claim54, wherein said removal or destruction of at least one applicationcomprises removal or destruction according to a hierarchy or priorityscheme.
 56. The apparatus of claim 55, wherein said hierarchy orpriority scheme comprises an MHP-compliant destruction hierarchy orscheme.
 57. The apparatus of claim 55, wherein said hierarchy orpriority scheme comprises an OCAP-compliant destruction hierarchy orscheme.
 58. The apparatus of claim 51, wherein said events compriseevents relating contention for said at least one resource, and saidhandling comprises implementation of a priority or hierarchy scheme formaking said at least one resource available.
 59. The apparatus of claim51, wherein said content delivery network comprises a hybrid deliverynetwork having both optical fiber and non-fiber portions.
 60. The methodof claim 59, wherein said non-fiber portion of said content deliverynetwork comprises a metallic conductor bearer medium.
 61. The apparatusof claim 51, wherein said content delivery network comprises a satellitedelivery network.
 62. The apparatus of claim 51, wherein said middlewarecomprises Digital Television Application Software Environment (DASE)compliant middleware.
 63. Apparatus adapted for operation within acontent distribution network, said apparatus comprising: a networkinterface adapted for communication with said content distributionnetwork; a digital processor; a storage device operatively coupled tosaid processor; middleware adapted to run on said processor; andsoftware comprising a plurality of privileged application programminginterfaces (APIs), said privileged APIs adapted to be accessed by only amonitor application with special permission to do so; wherein said APIsare further adapted to enable at least one of the reporting and handlingof events occurring within said apparatus, said events relating to atleast one resource of said apparatus.
 64. The apparatus of claim 63,wherein said events occurring within said apparatus are taken from thegroup consisting of: (1) recoverable error types; (ii) catastrophicerror types; and (iii) resource depletion events.
 65. The apparatus ofclaim 63, wherein said handling comprises removal or destruction of atleast one application resident on said apparatus.
 66. The apparatus ofclaim 65, wherein said removal or destruction of at least oneapplication comprises removal or destruction according to a MultimediaHome Platform (MHP)-compliant hierarchy or priority scheme.
 67. Theapparatus of claim 65, wherein said removal or destruction of at leastone application comprises removal or destruction according to anOpenCable (OCAP)-compliant destruction hierarchy or scheme.
 68. Theapparatus of claim 63, wherein said monitor application comprises atrusted monitor application.
 69. The apparatus of claim 63, wherein saidevents comprise events relating contention for said at least oneresource, and said handling comprises implementation of a priority-basedscheme for making said at least one resource available.
 70. Theapparatus of claim 63, wherein said content distribution networkcomprises a hybrid delivery network having both optical fiber andnon-fiber portions.
 71. The method of claim 70, wherein said non-fiberportion of said delivery network comprises a metallic conductor bearermedium.
 72. The apparatus of claim 63, wherein said content distributionnetwork comprises a satellite delivery network.
 73. The apparatus ofclaim 63, wherein said middleware is compliant with Multimedia andHypermedia Experts Group (MHEG) standards.
 74. A method of operatingclient equipment in operative communication with an information network,said equipment comprising at least at least a privileged firstapplication and a second application, said method comprising: detectingat least one error in the operation of said client equipment;determining a type of said at least one detected error; selectivelyinitiating at least one action based at least in part on said determinedtype; and storing at least a portion of data relating to said errorwithin a storage device; wherein said acts of determining andselectively initiating are performed substantially by said privilegedfirst application; and wherein said act of detecting is performedsubstantially by said second application.
 75. The method of claim 74,wherein said first application comprises an OpenCable (OCAP)-compliantapplication running on said client equipment.
 76. The method of claim74, wherein said information network comprises a hybrid optical fiberand non-fiber delivery network.
 77. The method of claim 74, wherein saidat least one error comprises either a catastrophic error or arecoverable error.
 78. The method of claim 74, wherein said type of saidat least one detected error comprises at least one of: (i) informationalmessage types; (ii) recoverable error types; (iii) catastrophic errortypes; (iv) reboot events; and (v) resource depletion events.
 79. Themethod of claim 74, wherein said act of selectively initiating at leastone action comprises generating a message for transmission to anotherentity.
 80. The method of claim 74, wherein said information networkcomprises a multi-channel cable distribution network, and said clientequipment comprises an OCAP-complaint host device adapted for use withsaid cable distribution network.
 81. The method of claim 74, whereinsaid information network comprises a multi-channel satellitedistribution network, and said client equipment comprises anMHP-complaint host device adapted for use with said satellitedistribution network.
 82. Apparatus adapted for operation within acontent distribution network, said apparatus comprising: a networkinterface adapted for communication with said content distributionnetwork; a digital processor; a storage device operatively coupled tosaid processor; middleware adapted to run on said processor; andsoftware adapted to run on said processor and comprising a plurality ofapplication programming interfaces (APIs), said APIs adapted to at leastsupport a trusted monitor application, said trusted monitor applicationbeing configured to: detect one or more events occurring within saidapparatus relating to at least one resource of said apparatus; and takeone or more actions with respect to said detected one or more events.83. The apparatus of claim 82, wherein said APIs adapted to at leastsupport a trusted application comprise Java classes and methodsparticularly adapted for said at least support of said trustedapplication.
 84. The apparatus of claim 82, wherein said contentdistribution network comprises at least one of: a cable televisionnetwork; a satellite content network; and a wireless Code DivisionMultiple Access (CDMA) network.
 85. The apparatus of claim 82, whereinsaid one or more actions taken comprises reporting said one or moreevents to an entity in communication with said apparatus via saidnetwork.
 86. The apparatus of claim 82, wherein said one or more eventscomprise hardware contention events and said one or more actions takencomprises removal or destruction of at least one application resident onsaid apparatus.
 87. The apparatus of claim 86, wherein said removal ordestruction of at least one application comprises removal or destructionaccording to a hierarchy or priority scheme.
 88. The apparatus of claim82, wherein said one or more events comprise hardware failure events andsaid one or more actions taken comprise corrective actions to remedysaid hardware failure.
 89. The apparatus of claim 88, wherein if it isdetermined that said corrective actions do not remedy said hardwarefailure, said trusted monitor application further configured to reportsaid hardware failure to a network entity.
 90. The apparatus of claim82, wherein said middleware comprises at least one of: Multimedia Home.Platform (MEW) compliant middleware; Multimedia and Hypermedia ExpertsGroup (MHEG) compliant middleware; and Digital Television ApplicationSoftware Environment (DASE) compliant middleware.
 91. Apparatus adaptedfor operation within a hybrid optical fiber and non-fiber deliverynetwork, said apparatus comprising: a network interface adapted forcommunication with said hybrid network; a digital processor; a storagedevice operatively coupled to said processor; and a plurality ofprivileged application programming interfaces (APIs) adapted to beaccessed by an application with special permission to do so; whereinsaid privileged APIs are further adapted to enable detection of errorevents occurring within said apparatus; wherein said events relate to atleast one resource of said apparatus; and wherein said error eventscomprise either hardware failure events or contention events.
 92. Amethod of ensuring effective operation of client equipment in aninformation network, said method comprising: detecting at least oneoperational error of said client equipment at a first application, saidfirst application generating first data relating to said at least oneoperational error; and receiving said first data at a secondapplication, said second application comprising a privileged applicationconfigured to cause at least one action to be taken at said clientequipment based at least in part on said data relating to said at leastone operational error; wherein said at least one operational errorcomprises at least one event relating to contention for at least oneresource of said client equipment, and said at least one actioncomprises implementation of a scheme for making said at least oneresource available.